From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Charles Hauser <chauser(at)duke(dot)edu>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: problem fetching currval of sequence |
Date: | 2002-08-06 18:35:20 |
Message-ID: | 200208061135.20799.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom,
> 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).
No, back in 7.1.0 I was able to call CURRVAL without having previously called
NEXTVAL, and it would give me the "current" sequence value; that is, the same
result value as (NEXTVAL() - 1); I wouldn't mind having a new function that
does this; I can understand making a distinction between the pre-session
CURRVAL, and the general current value.
> 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".
Me, I use functions.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-06 20:18:45 | Re: problem fetching currval of sequence |
Previous Message | Jean-Luc Lachance | 2002-08-06 17:53:50 | Re: SQL syntax |