More on elog and error codes

I've looked at the elog calls in the source, about 1700 in total (only
elog(ERROR)).  If we mapped these to the SQL error codes then we'd have
about two dozen calls with an assigned code and the rest being "other".
The way I estimate it (I didn't really look at *each* call, of course) is
that about 2/3 of the calls are internal panic calls ("cache lookup of %s
failed"), 1/6 are SQL-level problems, and the rest are operating system,
storage problems, "not implemented", misconfigurations, etc.

A problem that makes this quite hard to manage is that many errors can be
reported from several places, e.g., the parser, the executor, the access
method.  Some of these messages are probably not readily reproduceable
because they are caught elsewhere.

Consequentially, the most pragmatic approach to assigning error codes
might be to just pick some numbers and give them out gradually.  A
hierarchical subsystem+code might be useful, beyond that it really depends
on what we expect from error codes in the first place.  Does anyone have
good experiences from other products?

Essentially, I envision making up a new function, say "elogc", which has
   elogc(<level>, [<subsys>,?] <code>, message...)

where the code is some macro, the expansion of which is to be determined.
A call to "elogc" would also require a formalized message wording, adding
the error code to the documentation, which also requires having a fairly
good idea how the error can happen and how to handle it.  This could
perhaps even be automated to some extent.

All the calls that are not converted yet will be assigned a to the generic
"internal error" class; most of them will stay this way.


As for translations, I don't think we have to worry about this right now.
Assuming that we would use gettext or something similar, we can tell it
that all calls to elog (or "elogc" or whatever) contain translatable
strings, so we don't have to uglify it with gettext(...) or _(...)  calls
or what else.


So we need some good error numbering scheme.  Any ideas?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/