Re: [GENERAL] using ID as a key

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

In response to

Responses

Browse pgsql-general by date

  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