From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Aaron J(dot) Seigo" <aaron(at)gtv(dot)ca> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Getting OID in psql of recent insert |
Date: | 1999-11-19 05:40:02 |
Message-ID: | 1195.942990002@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Aaron J. Seigo" <aaron(at)gtv(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-11-19 05:50:32 | Re: [HACKERS] psql & regress tests |
Previous Message | Bruce Momjian | 1999-11-19 04:58:19 | Re: [HACKERS] Primary key requires SERIAL |