Skip site navigation (1) Skip section navigation (2)

Re: [NOVICE] Last ID Problem

From: John Hansen <john(at)geeknet(dot)com(dot)au>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [NOVICE] Last ID Problem
Date: 2005-02-03 02:46:50
Message-ID: 1107398810.26839.24.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
> Attempts to return the id of the last value to be inserted into a table.
> You can either provide a sequence name (preferred) or provide a table
> name with optional schema. The $catalog and $field arguments are always ignored.
> The current value of the sequence is returned by a call to the
> 'currval' PostgreSQL function. This will fail if the sequence has not yet
> been used in the current database connection.


This suffers from the same problems that currval does when using
connection pools tho.
 
I previously suggested a function similar to last_insert_id in behaviour,
and have attached it to this email for reference.

Even so, this also suffers from the same problems when using a connection pool.

The solution I proposed, namely having the tuple returned by
inserts/updates (perhaps even deletes?) would only mean changing the
client library to handle this, and as an example, libpg could easily
figure out the OID of said tuple and return that if it's present for
PQExec() (for backwards compatibility just as it does today,) and add a
separate PQExecSelect() that instead returns the tuple(s) as if they had
been SELECTed.

-- 
John Hansen <john(at)geeknet(dot)com(dot)au>
GeekNET

Attachment: Makefile
Description: text/x-makefile (321 bytes)
Attachment: lastval.sql
Description: text/x-sql (396 bytes)
Attachment: lastval.c
Description: text/x-csrc (383 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-02-03 03:16:10
Subject: Re: libpq API incompatibility between 7.4 and 8.0
Previous:From: Greg Sabino MullaneDate: 2005-02-03 02:09:20
Subject: Re: [NOVICE] Last ID Problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group