Re: [INTERFACES] locking on database updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] locking on database updates
Date: 1999-12-08 06:53:30
Message-ID: 25814.944636010@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

"Ross J. Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)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

Browse pgsql-interfaces by date

  From Date Subject
Next Message Peter Mount 1999-12-08 07:26:29 RE: [INTERFACES] Transaction support in 6.5.3/JDBC
Previous Message Tom Lane 1999-12-08 06:40:16 Re: [INTERFACES] sql question