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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
lastval.c text/x-csrc 383 bytes
lastval.sql text/x-sql 396 bytes
Makefile text/x-makefile 321 bytes

In response to

Responses

Browse pgsql-hackers by date

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