Alvaro Herrera wrote:
> Sent: Thursday, May 12, 2005 6:36 AM
> To: John Hansen
> Cc: Bruce Momjian; Neil Conway; Dennis Bjorklund;
> pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] lastval()
>
> On Thu, May 12, 2005 at 04:58:54AM +1000, John Hansen wrote:
> > Alvaro Herrera wrote:
>
> > > Actually, having it throw an error would be helpful, because then
> > > you can find in the application which calls should be replaced by
> > > the generic runquery() that has to return nothing versus the one
> > > that has to return a sequence value. So porting is a little more
> > > involved but more useful in the end.
> >
> > Indeed, but my point was that often it is going in the too
> hard basket.
> > Not that I disagree, but how do you predetermine which
> queries would
> > throw an error if they're built dynamically?
>
> 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 when
thetable is one of those containing a serial primary key. Not very elegant, which is why I'd like to see at least the
lastval(false)method implemented.
>
> --
> Alvaro Herrera (<alvherre[a]surnet.cl>)
> "La fuerza no está en los medios físicos sino que reside en
> una voluntad indomable" (Gandhi)
... John
