On Thu, 18 Nov 1999, Bruce Momjian wrote:
> > If you want to attack this, I'd suggest thinking a little larger than
> > just the last-OID problem. I'd like to be able to save off both
> > insertion OIDs and values extracted by SELECTs into named variables
> > of some sort, and then insert those values into as many later commands
> > as I want. Right now there's no way to do any such thing in a psql
> > script; you have to move up a level of difficulty into ecpg or pgtcl
> > or even C code if your application needs this. Plain psql scripts
> > would become substantially more powerful if psql had a capability
> > like this.
>
we talked about this a few weeks ago as users... even those of us using C or
higher level scripting languages agreed it would be nice to be able to have
arbitrary values that are the result of an insert/update/delete able to be
returned, without a subsequent select. if this made it into postgres, i think
you'd have many happy users =)
> OK, I am dealing with this in the book. What are oids good for then?
>
i can tell you what i use them for as someone who works with postgres daily...
i'm not sure if this was what they were intended for.. but =)
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.
--
Aaron J. Seigo
Sys Admin
