Re: lastval()
От | Bruce Momjian |
---|---|
Тема | Re: lastval() |
Дата | |
Msg-id | 200505110330.j4B3U5e00850@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: lastval() (Abhijit Menon-Sen <ams@oryx.com>) |
Ответы |
Re: lastval()
Re: lastval() |
Список | pgsql-patches |
Abhijit Menon-Sen wrote: > At 2005-05-11 10:55:37 +1000, neilc@samurai.com wrote: > > > > > Here is a small patch that implements a function lastval() [...] > > > > What do people think of this idea? (Tom seems opposed, I'm just > > wondering if there are other opinions out there.) > > For what it's worth, I think it's a bad idea. > > In the MySQL wire protocol (hi Dennis!), the "last insert id" is sent > along with every "OK" message, and the client can just keep the value > in memory. Users call a function to retrieve that value, rather than > issuing a "SELECT nextval()". > > So the server-side lastval() function is not enough for any meaningful > compatibility. The client would also need to be changed to provide the > pgsql_last_insert_id() or a similar function (which could do a "SELECT > lastval()" internally). > > In this situation -- where both client changes AND a server round-trip > are required -- what's the point of adding cruft to the server? Might > as well confine changes to the client, and use nextval to implement > the feature. > > By the way, what would lastval() do if an insert trigger inserts a row > into a table with another serial column? It fails, just like it would fail now if the trigger inserted into the same table that used the trigger, or a rule. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: