Different gettext domain needed for error context - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Different gettext domain needed for error context
Date
Msg-id 4F3B72E0.8040801@enterprisedb.com
Whole thread Raw
Responses Re: Different gettext domain needed for error context
List pgsql-hackers
I just noticed that we use the same gettext domain for all messages 
attached to one error. That is wrong in case of context information, 
where you have a stack of context lines, originating from different 
modules. The result is that context lines don't always get translated.

For example:

postgres=# set lc_messages ='de_DE.utf8';
SET
postgres=# do $$
begin  select 1 / 0;
end
$$;
FEHLER:  Division durch Null
CONTEXT:  SQL-Anweisung »select 1 / 0«
PL/pgSQL function "inline_code_block" line 3 at SQL-Anweisung

Notice how the string "PL/pgSQL function ..." is not translated. The 
ereport call that raises that error is in int4div, which is in the 
backend gettext domain, "postgres". But the errcontext() call comes from 
pl_exec.c.

If the error originates from src/pl/plpgsql, then it works:

postgres=# do $$
begin  raise;
end
$$;
FEHLER:  RAISE ohne Parameter kann nicht außerhalb einer 
Ausnahmebehandlung verwendet werden
CONTEXT:  PL/pgSQL-Funktion »inline_code_block« Zeile 3 bei RAISE

In theory, I guess the other fields like errhint() potentially have the 
same problem, but they're not currently used to provide extra 
information to messages originating from another module, so I'm inclined 
to leave them alone for now.

To fix this, we need to somehow pass the caller's text domain to 
errcontext(). The most straightforward way is to pass it as an extra 
argument. Ideally, errcontext() would be a macro that passes TEXTDOMAIN 
to the underlying function, so that you don't need to change all the 
callers of errcontext():

#define errcontext(...) errcontext_domain(TEXTDOMAIN, ...)

But that doesn't work, because it would require varags macros. Anyone 
know a trick to make that work?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_test_fsync performance
Next
From: Christoph Berg
Date:
Subject: [trivial patch] typo in doc/src/sgml/sepgsql.sgml