Neil Padgett <npadgett@redhat.com> writes:
> I'm not sure how this format causes a problem with localization. The
> trailing bracketed text isn't part of the message text -- it's just a
> set of fields and values.
It *looks* like it is part of the message text --- to users, and to
programs that aren't specifically aware that it isn't. A user-friendly
client would need to take extra steps to strip out the (index=N) part
to avoid complaints from users that their error messages aren't getting
fully translated.
> So, since the keywords aren't really intended
> for raw display, they don't require translation. Parsing the format is
> no harder, and the raw output isn't as ugly as is a multi-line list of
> fields and values, IMHO. (I really dislike unnecessarily having gobs of
> output lines in the message.)
I don't much care for it either, and wouldn't propose it if this were
the sole application. However, we have other applications, as noted in
the previous discussion:
--- distinguishing the actual error message from tips/hints about what
to do about it. There are a fair number of these already, and right
now there's just a very weak formatting convention that hints
appear on a separate line.
--- distinguishing a translatable (primary) error message from a
maintainer error message that need not be translated. We have lots
and lots of errors in the backend that could all fit under a single
primary error code of "Internal error, please report this to
pgsql-bugs", thus vastly reducing the burden on message translators.
The maintainer error message (eg, "foobar: unexpected node type 124")
still needs to appear, but it could be a secondary field.
--- including backend file name and line number of the elog call, for
easier debugging and unambiguous identification of an error source.
--- severity level
--- doubtless other ideas will occur to us once we have the capability.
Given all these potential benefits, I'm willing to endure the downside
of slightly ugly-looking error reports in old clients. They'll still
*work*, mind you, and indeed emit info that users might like to have.
To the extent that it's clutter, people will be motivated to update
their clients. Doesn't seem like much of a downside.
regards, tom lane
