Re: Internationalized error messages - Mailing list pgsql-hackers

Tom Lane writes:

> There's a difficult tradeoff to make here, but I think we do want to
> distinguish between the "official error code" --- the thing that has
> translations into various languages --- and what the backend is actually
> allowed to print out.  It seems to me that a fairly large fraction of
> the unique messages found in the backend can all be lumped under the
> category of "internal error", and that we need to have only one official
> error code and one user-level translated message for the lot of them.

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.

> Another thing that's bothered me for a long time is our inconsistent
> approach to determining where in the code a message comes from.  A lot
> of the messages currently embed the name of the generating routine right
> into the error text.  Again, we ought to separate the functionality:
> the source-code location is valuable but ought not form part of the
> primary error message.  I would like to see elog() become a macro that
> invokes __FILE__ and __LINE__ to automatically make the *exact* source
> code location become part of the secondary error information, and then
> drop the convention of using the routine name in the message text.

These sort of things have been on my mind as well, but they're really
independent of my issue.  We can easily have runtime options to append or
not additional things to the error string.  I don't see this as part of my
proposal.

> Another thing that I missed in Peter's proposal is how we are going to
> cope with messages that include parameters.  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.

> That would mean we'd have to dump all the info into a single string,
> which is doable but would perhaps look pretty ugly:
>
>     ERROR: Attribute "foo" not found  -- basic message for dumb frontends
>     ERRORCODE: UNREC_IDENT        -- key for finding localized message

There should not be a "key" to look up localized messages.  Remember that
the localization will also have to be done in all the front-end programs.
Surely we do not wish to make a list of messages that pg_dump or psql
print out.  Gettext takes care of this stuff.  The only reason why we need
error codes is for the sake of ease of interpreting by programs.

>     PARAM1: foo    -- something to embed in the localized message

Not necessary.

>     MESSAGE: Attribute or table name not known within context of query

How's that different from ERROR:?

>     CODELOC: src/backend/parser/parse_clause.c line 345

Can be appended to ERROR (or MESSAGE) depending on configuration setting.

>     QUERYLOC: 22

Not all errors are related to a query.

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?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/