Re: Re: postgres TODO

Tom Lane wrote:
> 
> However, I still prefer the SELECT nextval() followed by INSERT approach
> over INSERT followed by SELECT currval().  It just feels cleaner.

This is the way I have been doing it, so I'm pleased to see you
endorsing it :-)

What I don't like about this way though is that I have to (A) do two
statements and (B) set up the permissions on my sequence as well as on
my table.  If I could just get the inserted tuple back somehow it would
definitely simplify my application.


> To get back to Peter's original question, you don't necessarily "know
> what you inserted" if you allow columns to be filled with default values
> that are calculated by complicated functions.  A serial column is just
> the simplest example of that.  Whether this situation is common enough
> to justify a special hack in INSERT is another question.  I kinda doubt
> it.  We already return the OID which is sufficient info to select the
> row again if you need it.  Returning the primary key would be
> considerably more work for no visible gain in functionality...

For some reason I find almost every situation in which I INSERT with a
SERIAL I want to provide user feedback that includes that allocated
SERIAL.  The use of primary keys is not restricted purely to in-database
storage - they can get transferred into people's brains and e-mailed
around the place and so on.

Getting that back from an INSERT would definitely be useful to me.

Thanks,                Andrew.

-- 
_____________________________________________________________________           Andrew McMillan, e-mail:
Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267