Re: Upgrading the backend's error-message infrastructure

On Thu, Mar 13, 2003 at 03:51:00PM -0500, Tom Lane wrote:
> Wire-protocol changes
> ---------------------
>
> Error and Notice (maybe also Notify?) msgs will have this structure:
>
> E
> x string \0
> x string \0
> x string \0
> \0
>
> where the x's are single-character field identifiers. A frontend should
> simply ignore any unrecognized fields. Initially defined fields for Error
> and Notice are:

...

> S,C,M fields will always appear (at least in Error messages; perhaps
> Notices might omit C?). The rest are optional.

It strikes me that this error response could be made slimmer by
removing the text fields.

It makes sense for P, F, L, and R to be returned when available, as
they're specific to the instance of the error. C is clearly necessary,
as well. S is questionable, though, depending on whether (for every C
there is one, and only one S).

But the others are going to be the same for every instance of a given
C. It would seem to make more sense to me to provide a different
function(s) which allows the lookup Messages, Details, and Hints based
on the SQLSTATE.

The benefits that i see would be:

- Less clutter and wasted space on the wire. If we are concerned
enough about space to reduce the SQLSTATE to an integer mapping,
removing all the extra text should be a big win. Couple this with the
libraries' ability to now do things like cache messages, or not bother
to retrieve messages for certain SQLSTATEs, and the benefit gets
larger.

- Removal of localization from error/notice generation libraries. This
should make that section of code simpler and more fault-tolerant. It
also allows libraries to do potentially weird stuff like using
multiple different locales per connection, so long as they can specify
a locale for the lookup functions.

Does that make sense, or am i missing something?

-johnnnnnnnnnn