Re: Re: postgres TODO
От | Tom Lane |
---|---|
Тема | Re: Re: postgres TODO |
Дата | |
Msg-id | 722.963242095@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: postgres TODO (Alessio Bragadini <alessio@albourne.com>) |
Ответы |
Re: Re: postgres TODO
RE: Re: postgres TODO |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: