From: | Abhijit Menon-Sen <ams(at)oryx(dot)com> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | db(at)zigo(dot)dhs(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: lastval() |
Date: | 2005-05-11 02:52:46 |
Message-ID: | 20050511025246.GB13619@penne.toroid.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
At 2005-05-11 10:55:37 +1000, neilc(at)samurai(dot)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?
-- ams
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-11 03:30:05 | Re: lastval() |
Previous Message | Andrew Dunstan | 2005-05-11 02:33:31 | Re: lastval() |
From | Date | Subject | |
---|---|---|---|
Next Message | John Hansen | 2005-05-11 03:20:04 | Re: lastval() |
Previous Message | Andrew Dunstan | 2005-05-11 02:33:31 | Re: lastval() |