Re: lastval()

Bruce Momjian wrote:
> Sent: Wednesday, May 11, 2005 1:45 PM
> To: John Hansen
> Cc: Neil Conway; Dennis Bjorklund; pgsql-patches(at)postgresql(dot)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