Re: undefine currval() - Mailing list pgsql-sql

From scott.marlowe
Subject Re: undefine currval()
Date
Msg-id Pine.LNX.4.33.0309081701100.12311-100000@css120.ihs.com
Whole thread Raw
In response to Re: undefine currval()  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: undefine currval()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
On Mon, 8 Sep 2003, Bruce Momjian wrote:

> I don't know how you could have an application that doesn't know if it
> has issued a nextval() in the current connection. Unless you can explain
> that, we have no intention of playing tricks with currval() for
> connection pooling.

Actually, I would think the very act of using connection pooling would 
ensure that applications may well not know whether or not a nextval had 
been called.  In other words, how is an application supposed to know if 
the previous bit of code that used this connection issued a nextval() when 
you're connection pooling and any piece of code could have run before you.

On the other hand, using currval as a test to see if a value has been used 
is probably not the best way of doing things either.  I'd imagine some 
kind of static or session var would be better suited to that task.



pgsql-sql by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: undefine currval()
Next
From: Tom Lane
Date:
Subject: Re: undefine currval()