Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id BAA13501
	for <pgsql-interfaces@postgreSQL.org>;
	Wed, 8 Dec 1999 01:54:06 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA25816;
	Wed, 8 Dec 1999 01:53:30 -0500 (EST)
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] locking on database updates 
In-reply-to: Your message of Tue, 7 Dec 1999 13:24:11 -0600
	<19991207132411.B7090@rice.edu>
Date: Wed, 08 Dec 1999 01:53:30 -0500
Message-ID: <25814.944636010@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> Tom - 
> I'm surprised: that one's been beat to death in earlier incarnations
> of this FAQ. The currval() function is part of backend state: it
> always returns the last value sent to _this connection_.

Yeah, sure, I knew that ... in one brain cell or another, but evidently
not the ones on call today ;-)

A fairly weak rejoinder: if you've got triggers or rules doing things
to your tables behind-your-back, you might still not be able to assume
that the sequence's nextval() will be called only once during any one
SQL query that you issue.  So I still say the nextval-first approach
is sounder than currval-afterwards.  But I must agree it wouldn't
become an issue unless you had some pretty convoluted database
programming going on.

			regards, tom lane