Re: [GENERAL] using ID as a key
От | Ed Loehr |
---|---|
Тема | Re: [GENERAL] using ID as a key |
Дата | |
Msg-id | 389F1EF1.3990E500@austin.rr.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] using ID as a key (<kaiq@realtyideas.com>) |
Ответы |
Re: [GENERAL] using ID as a key
|
Список | pgsql-general |
kaiq@realtyideas.com wrote: > > On Mon, 7 Feb 2000, Ed Loehr wrote: > > > These are resolvable problems. One way to do a programmatic ID > > generation as David B. suggests is to have a DB server whose purpose > > is to issue "seed numbers" which designate, through use of a > > pre-determined multiplier, a *range* of allocated IDs guaranteed to be > > unique across all seed requesters. This avoids both of the problems > > raised above (throughput and synchronization). > > sounds familiar -- the seed server can be pg, and other servers can be > user-program, and pg's sequence can do this already. Yes, coincidentally, very similar to sequence cache functionality in principle, as someone pointed out. [Wish I'd had those sequence objects when we did the implementation...] > and, it seems not "programmatically at all. What would make it "programmatic" in my view would be calling a function, as in "$newID = GetNewID()", prior to INSERT and then using the returned ID value in your INSERT, rather than using a 'default nextval' to get the value. I don't see why one wouldn't want to use a sequence object within GetNewID(), FWIW. But sounds like it is not the kind of programmatic example/explanation you were looking for... Cheers, Ed Loehr
В списке pgsql-general по дате отправления: