Re: lastval()

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

In response to

Responses

Browse pgsql-hackers by date

  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()

Browse pgsql-patches by date

  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()