Re: Patch for Improved Syntax Error Reporting

Tom Lane wrote:
>
> 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.
>

This is exactly what I want. If you don't have a new client, it looks
like a message with some funk on the end. If you have a new, friendly
client, it will strip out the field/value list at the end. Exactly the
same as the multi-line list, really. And the translation complaint is
equally applicable to either format.

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

I didn't know that such a convention exists already -- how would these
hints look under your proposed new format?

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

Why aren't we using numerics to do this? I recall reading something (in
the archives?) about them before, but I don't recall the outcome. Is
anything like numerics being added to help with the localization
efforts? It would seem this is the best way to handle primary errors,
versus maintainer errors.

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

Hmm... You could do any of these with either format, but I'm starting to
that with this many fields, any message in my suggested format is
probably going to wrap. So I'm pretty much sold on a multi-line format.
(It might even be less ugly for messages with lots of fields!)

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

No, I don't think so either. It seems that this new format makes sense.
Would the elog call be changed to support passing in a list of
arguments? Or are you proposing we just hard code the field name / value
lists into the messages? (a bad idea, IMHO) We should probably introduce
a new call, say, eelog (for enhanced error log) that takes such a list,
and then we could define elog as a macro which calls eelog with suitable
defaults for use with "legacy" messages. Then, we wouldn't need to go
after every error message right away. (And in fact, probably, in the
case of soem rare messages. need not ever.)

The question this brings up is whether a logging change can / should be
tackled in this release. Specifically, with the current state of
internationalization work, is it best to do it now, or later? Or, for
now, should we just decide on an output format, and then hardcode the
field output for just the syntax error reporting, leaving everything
else to be tackled later?

Neil

--
Neil Padgett
Red Hat Canada Ltd.                       E-Mail:  npadgett@redhat.com
2323 Yonge Street, Suite #300,
Toronto, ON  M4P 2C9