From: | Ed Loehr <eloehr(at)austin(dot)rr(dot)com> |
---|---|
To: | kaiq(at)realtyideas(dot)com |
Cc: | sevo(at)ip23(dot)net, davidb(at)vectormath(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] using ID as a key |
Date: | 2000-02-07 19:37:21 |
Message-ID: | 389F1EF1.3990E500@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
kaiq(at)realtyideas(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2000-02-07 20:10:08 | Re: [GENERAL] using ID as a key |
Previous Message | Ed Loehr | 2000-02-07 19:23:10 | Re: [GENERAL] using ID as a key |