Re: error codes - Mailing list pgsql-hackers

Neil Conway writes:

> I'd like to implement error codes. I think they would be pretty useful,
> although there are a few difficulties in the implementation I'd like
> to get some input on.

OK, allow me to pass on to you the accumulated wisdom on this topic. :-)

> Should every elog() have an error code?

The set of error codes should primarily be that defined by SQL99 part 2
clause 22 "Status codes" and PostgreSQL extensions that follow that
spirit.  That means that all those "can't happen" or "all is lost anyway"
types should be lumped (perhaps in some implicit way) under "internal
error".  That means, yes, an error code should be returned in every case
of an error, but it doesn't have to be a distinct error code for every
condition.

> How should the backend code signal an error with an error number?

> The problem here is that many errors will require more information
> that that, in order for the client to handle them properly. For
> example, how should a COPY indicate that an RI violation has
> occured? Ideally, we'd like to allow the client application to
> know that in line a, column b, the literal value 'c' was
> not found in the referenced column d of the referenced table d.

Precisely.  You will find that SQL99 part 2 clause 19 "Diagnostics
management" defines all the fields that form part of a diagnostic (i.e.,
error or notice).  This includes for example, fields that contain the name
and schema of the table that was involved, if appropriate.  (Again,
appropriate PostgreSQL extensions could be made.)  It is recommendable
that this scheme be followed, so PL/pgSQL and ECPG, to name some
candidates, could implement the GET DIAGNOSTICS statement as in the
standard.  (Notice that, for example, a diagnostic still contains a text
message in addition to a code.)

> How should the error number be sent to the client, and would this
> require an FE/BE change? I think we can avoid that: including the
> error number in the error message itself, make PQgetErrorMessage()
> (and similar funcs) smart enough to remove the error number, and
> add a separate function (such as PQgetErrorNumber() ) to report
> the error number, if there is one.

I would advise against trying to cram everything into a string.  Consider
the extra fields explained above.  Consider being nice to old clients.
Also, libpq allows that more than one error message might arrive per query
cycle.  Currently, the error messages are concatenated.  That won't work
anymore.  You need a new API anyway.  You need a new API for notices, too.

One possiblity to justify a protocol change is to break something else
with it, like a new copy protocol.

> On a related note, it would be nice to get a consistent style of
> punctuation for elog() messages -- currently, some of them end
> in a period (e.g. "Database xxx does not exist in the system
> catalog."), while the majority do not. Which is better?

Yup, we've talked about that some time ago.  I have a style guide mostly
worked out for discussion.

> It would be relatively easy to replace elog() with a macro of
> the form:
>
> #define elog(...) real_elog(__FILE__, __LINE__, __VA_ARGS__)
>
> And then adjust real_elog() to report that information as
> appropriate.

And it would be relatively easy to break every old compiler that way...

-- 
Peter Eisentraut   peter_e@gmx.net