Thread: [HACKERS] elog vs errmsg_internal

[HACKERS] elog vs errmsg_internal

From
Peter Eisentraut
Date:
Is there a preferred method to select between using elog() and
errmsg_internal()?

Attached is a patch that converts some DEBUG messages to one of those
two to remove them from translation, but I'm not sure which one to pick
other than by random aesthetics.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

Re: [HACKERS] elog vs errmsg_internal

From
Alvaro Herrera
Date:
Peter Eisentraut wrote:
> Is there a preferred method to select between using elog() and
> errmsg_internal()?
> 
> Attached is a patch that converts some DEBUG messages to one of those
> two to remove them from translation, but I'm not sure which one to pick
> other than by random aesthetics.

I think the contrib changes are probably not useful, since contrib is
not a target for nls anyway.

I'm not sure that all DEBUG messages should stay untranslated.  If main
log messages (i.e. NOTICE/LOG and above) are translated, why not debug?
For example the ones in index.c and indexcmds.c.  I agree that many of
these debugs are useless when translated, but not all.  Clearly, it's a
judgement call which ones to mark for translation.

Some other random thoughts in the same area:

* I think translated messages in the server log are mostly an
operational failure.  I think we should default to C, perhaps offer
translation as an option that's not enabled by default.  Of course,
messages sent to client should be translated just like currently.

* Much worse is the fact that we send messages to the log in the
database encoding.  This means that having a server log mixing lines
from databases with different encodings is a failure; it's just not
possible to read the log at all.  A simple fix would be to transliterate
all messages to some common encoding (UTF8) so that at the log
file can at least be opened.  Another fix would be to have multiple log
files, one per encoding; or maybe go for one per database.  Neither of
these proposals seem particularly great.  Simply keeping the server log
in C locale would fix this problem too.




-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: [HACKERS] elog vs errmsg_internal

From
Tom Lane
Date:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Is there a preferred method to select between using elog() and
> errmsg_internal()?

ereport(... errmsg_internal() ...) can be a win for debug messages that
are in hot code paths, because the test for whether the message will
get printed is able to short-circuit more work.  In particular,
if you have moderately expensive functions like syscache lookups in
the argument list of elog(), I believe those functions get evaluated
even if we end up not printing anything.  ereport() skips the
arg-list evaluation in such cases.

But if that doesn't seem very relevant, I'd tend to go for elog()
just because it's less typing.
        regards, tom lane