error codes

From: nconway(at)klamath(dot)dyndns(dot)org (Neil Conway)
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: error codes
Date: 2002-07-17 18:27:39
Message-ID: 20020717182739.GB5542@klamath.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Should every elog() have an error code? I'm not sure -- there are many
elog() calls that will never been seen by the user, since the error
they represent will be caught before control reaches the elog (e.g.
parse errors, internal consistency checks, multiple elog(ERROR)
for the same user error, etc.) Perhaps for those error messages
that don't have numbers, we could just give them ERRNO_UNKNOWN or
a similar constant.

How should the backend code signal an error with an error number?
Perhaps we could report errors with error numbers via a separate
function, which would take the error number as its only param.
For example:

error(ERRNO_REF_INT_VIOLATION);

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.

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.

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?

Also, I think it was Bruce who mentioned that it would be nice
to add function names, source files, and/or line numbers to error
messages, instead of the current inconsistent method of sometimes
specifying the function name in the elog() message. Would this
be a good idea? Should all errors include this information?

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.

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-07-17 18:45:08 Re: fmtId() and pg_dump
Previous Message Tom Lane 2002-07-17 17:43:50 Re: [HACKERS] why is postgres estimating so badly?