Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> IMHO, the use of error messages in PostgreSQL has a big conceptual
> problem. It's only too tempting to write elog(ERROR, "I don't know what to
> do now.") anywhere and any time. This is very convenient for the
> developers but not very nice for client applications that want to
> recognize, categorize, and recover from errors.

The vast majority of the one-off error messages are internal consistency
checks. It seems to me that a workable compromise is to insist on
standardized error codes/texts for reporting user mistakes, but to
continue to allow spur-of-the-moment messages for internal errors.
Most or all internal errors would have the same classification anyway
from the point of view of an application trying to decide what to do,
so they could all share one or a few "error ID numbers".

> A necessary extension to the above would be a way to pass along supportive
> data. The tricky part will be to figure out a syntax that is not too
> cumbersome, not too restrictive, and encourages help by the compiler.

A printf/elog-like syntax should still work --- the message catalog that
PGE_TRIGGERED_DATA_CHANGE_VIOLATION indexes into would contain strings
that still have %-escapes, but that shouldn't make life any more
difficult for internationalization. And we do have the opportunity
to check mistakes with gcc, if we stick to the standard printf escapes.

Or do we? Hmm ... not if the error message text isn't available at
the call site ... Here's a thought: suppose that error code macros like
PGE_TRIGGERED_DATA_CHANGE_VIOLATION normally expand to an error code
number, which eventually gets used as an index into a localizable table
of error format strings; but we have the option to run with header files
that define all these macros as the actual error message literal
strings. Then gcc could check for parameter mismatch in that case.
For development work that might even be the normal thing, and only
in production scenarios would you introduce the extra level of
indirection to get to an error message string.

> In any case, I believe that the actual error message string should be
> assembled in the front-end.

That will not work, because the set of possible error messages will
undoubtedly change with every backend release, and we do *not* want
to get into a situation where out-of-date clients mean you get no
error message (or worse, a wrong error message). It will be better
to have the message table on the backend side. As long as the backend
ships an identifying code number along with the message text, I think
that will satisfy the needs of applications to avoid reverse-parsing
error messages.

Other than that, I agree with everything you say ;-)

> Comments? Anyone interested? This would be very dear to my heart so I'd be
> very willing to spend a lot of time on it.

It will take a lot of time to clean this up, but I think everyone agrees
we need to do it. It's just been a matter of someone taking on the job.

regards, tom lane