> "Aaron J. Seigo" <aaron@gtv.ca> writes:
> > On Thu, 18 Nov 1999, Bruce Momjian wrote:
> >> OK, I am dealing with this in the book. What are oids good for then?
>
> > once inserted, a row keeps its oid. so, when performing complex
> > selects, i'll often grab the oid too... do some tests on the returned
> > values, and if an action is appropriate on that row, i reference it by
> > its oid. the only chance of this failing is if the database is dumped
> > then restored between the select and the update (not gonna happen, as
> > the program requires the database available for execution)... using
> > the oid this way, its often simpler and faster to update a known row,
> > especially when the initial select involved many fields.
>
> Yes, I use 'em the same way. I think an OID is kind of like a pointer
> in a C program: good for fast, unique access to an object within the
> context of the execution of a particular application (and maybe not
> even that long). You don't write pointers into files to be used again
> by other programs, though, and in the same way an OID isn't a good
> candidate for a long-lasting reference from one table to another.
My feeling was that oid's are fine for joins in cases where the number
is not visible to the user, because they are not sequential. Does that
make sense, or is that too broad a usage?
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026