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

At 06:50 PM 2/24/00 -0500, Bruce Momjian wrote:
>> In any case, I believe that the actual error message string should be
>> assembled in the front-end. I'm not too fond of the idea of letting
>> clients parse out the interesting parts of an error out of a blob of text.
>>
>> 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.
>
>Vadim strongly believes in error mesage numbers. We certainly should do
>better, if only to print a code before the error code or something.

I do, too. Anyone else with a language implementation background is likely
to share that bias.

For starters ... you can at least imagine doing things like provide error
messages in languages other than English. Actually...Vadim could probably
force the issue by commiting a version with all the error messages in
Russian! Hmmm...wonder if he's thought of that? :)

And for applications it often makes a lot more sense to just get a
defined code.

When I improved on the AOLserver driver for Postgres, one of my goals
was to have it survive the closing of a backend. This gets less
crucial with each bug fix, but, heck ... the backend still pees its
pants and crashes occasionally, let's face it. In this case, the
driver wants to reestablish the connection to the backend (because
it's being managed as part of a persistent pool of connections by
the web server) but return an error.

Afterwards, all other backends close themselves and pass back a
delightfully wordy message that one should retry their query because
it didn't really crash, but rather is closing just in case shared
memory has been corrupted by the very naughty backend that really
did crash. In this case, the driver wants to reconnect and
retry the query, and if it succeeds return normally, with the
web server none the wiser.

(works great, BTW)

There's no documented way to distinguish between the two kinds of
backend closures that I could find. Interpreting the string in
general seems to be how one is expected to probe to determine exactly
what has happened, not only in this case but with other errors, too.

This sucks, IMO.

It turns out there's a trivial way to distinguish these two particular
cases I mention, without resorting to looking at the actual error message,
but I think it illustrates the general kludginess of returning strings
with no error code.

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