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

Re: Last ID Problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Mitch Pirtle <mitch(dot)pirtle(at)gmail(dot)com>,operationsengineer1(at)yahoo(dot)com, pgsql-novice(at)postgresql(dot)org
Subject: Re: Last ID Problem
Date: 2005-02-01 05:56:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-novice
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Mon, Jan 31, 2005 at 08:55:22PM -0500, Mitch Pirtle wrote:
>> 'Common', unfortunately, is relative; and in this matter might only
>> apply to ADOdb ;-)

> The world's bigger than a couple of PHP modules :-)  Calling currval()
> after an INSERT is a common way to get the sequence value when using
> PostgreSQL, regardless of the programming language or API being
> used.

His point stands though: if you are accessing Postgres through some kind
of connection-pooling software, currval() cannot be trusted across
transaction boundaries, since the pool code might give your connection
to someone else.  In this situation the nextval-before-insert paradigm
is the only way.

(But in most of the applications I can think of, your uses of currval
subsequent to an INSERT ought to be in the same transaction as the
insert, so are perfectly safe.  If your connection pooler takes control
away from you within a transaction block, you need a less broken

			regards, tom lane

In response to


pgsql-novice by date

Next:From: Michael FuhrDate: 2005-02-01 06:50:27
Subject: Re: Last ID Problem
Previous:From: Michael FuhrDate: 2005-02-01 05:30:13
Subject: Re: Last ID Problem

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-02-01 05:59:51
Subject: Re: patch for temporary view from TODO list
Previous:From: Michael FuhrDate: 2005-02-01 05:30:13
Subject: Re: Last ID Problem

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