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
