Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 67DB4475820 for ; Tue, 6 Aug 2002 12:29:32 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id C8315475813 for ; Tue, 6 Aug 2002 12:29:31 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g76GPiVk020612; Tue, 6 Aug 2002 12:25:44 -0400 (EDT) To: "Josh Berkus" Cc: Charles Hauser , pgsql-sql@postgresql.org Subject: Re: problem fetching currval of sequence In-reply-to: References: Comments: In-reply-to "Josh Berkus" message dated "Tue, 06 Aug 2002 08:45:45 -0700" Date: Tue, 06 Aug 2002 12:25:44 -0400 Message-ID: <20611.1028651144@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200208/98 X-Sequence-Number: 8944 "Josh Berkus" writes: > Sometime in the upgrade process for 7.1.0 --> 7.2.1, the CURRVAL > function changed so that it was rigorously session-specific. Huh? AFAIR it's always worked the way it does now (and a quick review of the CVS logs for sequence.c backs up my recollection). > ... it has the unfortunate > side effect that CURRVAL is virtually useless for querying the current > value of the row you just inserted using a front-end that creates a new > session for each command. Such a front end would be too broken to consider using anyway: if you cannot wrap several related commands into a transaction, you cannot use a database the way it's intended to be used. The connection-pooling front ends that I know about all give you dedicated use of a connection for at least the length of a transaction block, so the secret to using currval is "do it in the same transaction block as you call nextval in". regards, tom lane