Re: lastval() - Mailing list pgsql-patches

From Tom Lane
Subject Re: lastval()
Date
Msg-id 394.1115908123@sss.pgh.pa.us
Whole thread Raw
In response to Re: lastval()  ("John Hansen" <john@geeknet.com.au>)
List pgsql-patches
"John Hansen" <john@geeknet.com.au> writes:
>> Hmm, if your app can build any of them at an arbitrary point,
>> you have a rather serious problem, I'd say.  The apps I've
>> seen build either kind at each call site of such runquery().

> Actually, the app that I am referring to, does just that.
> However, in some instances, the only difference between two queries, would be the table name.
> A primary, with a serial as primary key, and a secondary without a serial.
> Inserting into the secondary, gives no sequence value, and thus currval() (or lastval()) would fail.
> I solved the error issue by hardcoding the table names available in runquery(), such that currval() is only called
whenthe table is one of those containing a serial primary key. Not very elegant, which is why I'd like to see at least
thelastval(false) method implemented. 

I continue to find this argument completely unconvincing.  If we provide
a function that works like that, then the result will be that whenever
you insert into the secondary table, your application will obtain and
use a completely WRONG answer --- namely the sequence value from some
other table entirely.  If your code is able to not do anything wrong as
a result, it seems to me it could refrain from calling the function in
the first place.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] plperl and pltcl installcheck targets
Next
From: Tom Lane
Date:
Subject: Re: AllocSetReset improvement