"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.
regards, tom lane