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

At 07:17 PM 2/24/00 -0500, Tom Lane wrote:

>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".

I have no problem with this. Why not just prepend them with an "internal"
error code? Clients can't really do much other than gasp "omigosh!" when
confronted with an internal error anyway...

>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.

Something like this sounds like a fine.

>> 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.

Yes, this is where it belongs. An application gets an error number,
then asks for a message to go with it if it wants one. Or, the
error's returned as an error code and message, either way.

> 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.

Yep.

>
>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.

Go, Peter!

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.