Re: lastval() - Mailing list pgsql-patches

From John Hansen
Subject Re: lastval()
Date
Msg-id 5066E5A966339E42AA04BA10BA706AE50A931F@rodrick.geeknet.com.au
Whole thread Raw
In response to lastval()  (Dennis Bjorklund <db@zigo.dhs.org>)
List pgsql-patches
Tom Lane wrote:
> Sent: Wednesday, May 11, 2005 3:41 PM
> To: John Hansen
> Cc: Neil Conway; Dennis Bjorklund; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] lastval()
>
> "John Hansen" <john@geeknet.com.au> writes:
> > I'm all for it. Even more so if the 'currval(void) called before
> > nextval(seq_name)' error message could be supressed by a
> GUC variable
> > and return 0 instead.
>
> I really have a hard time seeing the argument why that
> condition does not mean "your application is broken and you
> should fix it".

I'm _not_ saying that, I'm saying that the ports that would be a breeze
with this behaviour, probably won't happen without. Which is a shame.
Also note that I'm not suggesting this be the default behaviour. I'm not
even suggesting it be a configurable permanent (in fact it probably
shouldn't be configurable thru postgresql.conf), but merely a SET
parameter, that you can set prior to executing lastval(), or perhaps as
lastval(false/true);

> Much less why "0" is the correct response --- it's barely
> conceivable that you could persuade me that NULL is ok, but
> never a value that is a valid sequence value.

NULL would do fine.

>             regards, tom lane
>
>

... John

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: lastval()
Next
From: Mahmoud Taghizadeh
Date:
Subject: Where is Translation of "FARSI" FAQ?