Peter Eisentraut <peter_e@gmx.net> writes:
> That's exactly what I was trying to avoid. You'd still be allowed to
> choose the error message text freely, but client programs will be able to
> make sense of them by looking at the code only, as opposed to parsing the
> message text. I'm trying to avoid making the message text to be computed
> from the error code, because that obscures the source code.
I guess I don't understand what you have in mind, because this seems
self-contradictory. If "client programs can look at the code only",
then how can the error message text be chosen independently of the code?
>> Surely we do not expect gettext to start with 'Attribute "foo" not
>> found' and distinguish fixed from variable parts of that string?
> Sure we do.
How does that work exactly? You're assuming an extremely intelligent
localization mechanism, I guess, which I was not. I think it makes more
sense to work a little harder in the backend to avoid requiring AI
software in every frontend.
>> MESSAGE: Attribute or table name not known within context of query
> How's that different from ERROR:?
Sorry, I meant that as an example of the "secondary message string", but
it's a pretty lame example...
> The general problem here is also that this would introduce a client
> incompatibility. Older clients that do not expect this amount of detail
> will print all this garbage to the screen?
Yes, if we send it to them. It would make sense to control the amount
of detail presented via some option (a GUC variable, probably). For
backwards compatibility reasons we'd want the default to correspond to
roughly the existing amount of detail.
regards, tom lane
