Alessio Bragadini <alessio@albourne.com> writes:
> Peter Eisentraut wrote:
>>>> * Add function to return primary key value on INSERT
>>
>> I don't get the point of this. Don't you know what you inserted? For
>> sequences there's curval()
> Mmmhhh... it means that we can assume no update to the sequence value
> between the insert and the curval selection?
Yes, we can --- currval is defined to tell you the last sequence value
allocated *in this backend*.
Actually you could still get burnt if you had a sufficiently complicated
set of rules and triggers ... there could be another update of the
sequence induced by one of your own triggers, and if you forget to allow
for that you'd have a problem. But you don't have to worry about other
backends.
However, I still prefer the SELECT nextval() followed by INSERT approach
over INSERT followed by SELECT currval(). It just feels cleaner.
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...
regards, tom lane