Re: lastval()
От | Tom Lane |
---|---|
Тема | Re: lastval() |
Дата | |
Msg-id | 394.1115908123@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: lastval() ("John Hansen" <john@geeknet.com.au>) |
Список | pgsql-patches |
"John Hansen" <john@geeknet.com.au> writes: >> Hmm, if your app can build any of them at an arbitrary point, >> you have a rather serious problem, I'd say. The apps I've >> seen build either kind at each call site of such runquery(). > Actually, the app that I am referring to, does just that. > However, in some instances, the only difference between two queries, would be the table name. > A primary, with a serial as primary key, and a secondary without a serial. > Inserting into the secondary, gives no sequence value, and thus currval() (or lastval()) would fail. > I solved the error issue by hardcoding the table names available in runquery(), such that currval() is only called whenthe table is one of those containing a serial primary key. Not very elegant, which is why I'd like to see at least thelastval(false) method implemented. I continue to find this argument completely unconvincing. If we provide a function that works like that, then the result will be that whenever you insert into the secondary table, your application will obtain and use a completely WRONG answer --- namely the sequence value from some other table entirely. If your code is able to not do anything wrong as a result, it seems to me it could refrain from calling the function in the first place. regards, tom lane
В списке pgsql-patches по дате отправления: