Bruce Momjian wrote:
> Sent: Wednesday, May 11, 2005 1:45 PM
> To: John Hansen
> Cc: Neil Conway; Dennis Bjorklund; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] lastval()
>
> John Hansen wrote:
> > > > > What do people think of this idea? (Tom seems
> opposed, I'm just
> > > > > wondering if there are other opinions out there.)
> > > >
> > > > 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.
> > >
> > > Why zero and no error?
> >
> > That's the exact behaviour of the "other database's" equivalent.
> > Makes porting easier, and avoids hugely annoying error
> messages in the
> > logfiles.
>
> I think we would have to throw an error. It is hard to see
> how zero is a valid return value. If you are getting too
> many errors in your logs, fix the code.

Yes, that would be ideal, but most proting efforts seem to stall at the
'less trivial' problems.

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.

Now, I'm not saying this design is not broken to begin with, or that it
shouldn't be rewritten anyways,... I'm saying that for many applications
it won't happen because it's easier to just use another database
instead.

Besides, what's wrong with _knowingly_ telling the backend that: hey, I
know this query might throw an error, so just throw me a 0 instead if
you can't compute it?

.... John


---------------------------(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

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.

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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings