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>)
>
>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
