From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <cgg007(at)yahoo(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: undefine currval() |
Date: | 2003-09-08 23:03:39 |
Message-ID: | Pine.LNX.4.33.0309081701100.12311-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2003-09-08 23:05:38 | Re: [PATCHES] ISO 8601 "Time Intervals" of the "format with time-unit designators" |
Previous Message | Bruce Momjian | 2003-09-08 22:48:09 | Re: constraint modification on todo list |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-08 23:35:23 | Re: undefine currval() |
Previous Message | Bruce Momjian | 2003-09-08 22:41:00 | Re: undefine currval() |