Re: undefine currval()

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.

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-sql by date

  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()