"Jim C. Nasby" <jim@nasby.net> writes:
> Right now you don't. :( ISTM there should be a way to get back the row
> you just inserted. Whether a ctid is the right way to do that I don't
> know...
>
> I'm going to move this over to -hackers to see what people over there
> have to say.
Perhaps the right thing to provide would be a data structure that bundled up
the ctid and the transaction id. It would only be valid if the transaction id
still matched the current transaction id it was used in. Any attempt to use it
in a later transaction would give an error, much like using sequence.currval
when nextval hasn't been used.
Many people would suggest the right thing to be using is the primary key. And
there ought to be an interface to fetch the current value (or values) of the
primary key of the last inserted record.
The benefits of providing something based on ctid is to avoid the inefficiency
of the index lookup on the primary key and it would work on tables without any
primary key. I'm not sure it's worth the effort it would entail for those
narrow use cases especially since I think some interface to retrieve the
primary will still be needed anyways.
--
greg
