Re: error codes

Neil, attached are three email messages dealing with error message
wording.

I like Tom's idea of coding only the messages that are common/user
errors and leaving the others with a catch-all code.

We now have more elog levels in 7.3, so it should be easier to classify
the messages.

I can see this job as several parts:

---------------------------------------------------------------------------

Cleanup of error wording, removal of function names. See attached
emails for possible standard.

---------------------------------------------------------------------------

Reporting of file, line, function reporting using GUC/SET variable. For
function names I see in the gcc 3.1 docs at
http://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Standard-Predefined-Macros.html:

C99 introduces __func__, and GCC has provided __FUNCTION__ for a long
time. Both of these are strings containing the name of the current
function (there are slight semantic differences; see the GCC manual).
Neither of them is a macro; the preprocessor does not know the name of
the current function. They tend to be useful in conjunction with
__FILE__ and __LINE__, though.

My gcc 2.95 (gcc version 2.95.2 19991024) supports both __FUNCTION__ and
__func__, even though they are not documented in the info manual pages I
have. I think we will need a configure.in test for this because it
isn't a macro you can #ifdef.

---------------------------------------------------------------------------

Actual error code numbers/letters. I think the new elog levels will
help with this. We have to decide if we want error numbers, or some
pneumonic like NOATTR or CONSTVIOL. I suggest the latter.

---------------------------------------------------------------------------

I think we have plenty of time to get this done for 7.3.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026