Re: lastval() - Mailing list pgsql-patches

From John Hansen
Subject Re: lastval()
Date
Msg-id 5066E5A966339E42AA04BA10BA706AE50A9320@rodrick.geeknet.com.au
Whole thread Raw
In response to lastval()  (Dennis Bjorklund <db@zigo.dhs.org>)
Responses Re: lastval()
List pgsql-patches
Alvaro Herrera wrote:
> Sent: Wednesday, May 11, 2005 10:46 PM
> To: John Hansen
> Cc: Bruce Momjian; Neil Conway; Dennis Bjorklund;
> pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] lastval()
>
> On Wed, May 11, 2005 at 02:08:16PM +1000, John Hansen wrote:
>
> > Take for instance this (overly simplified) function used in
> a program
> > that builds the query strings dynamically:
> >
> > int64 runquery(char *query) {
> >     PQexec(query);
> >     result = Pqexec("SELECT lastval()");
> >     return result;
> > }
> >
> > The program expects this function to return the 'id' that was
> > inserted, or 0 if the table didn't contain a sequence or it
> wasn't an insert.
> >
> > Rewriting that would take a considerable effort.
>
> 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?

>
> --
> Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
>
>

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_autovacuum micro patch to display database name when
Next
From: Tom Lane
Date:
Subject: Re: Patch that deals with that AtCommit_Portals encounters