elog vs errmsg_internal
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37212psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 05:35 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37212_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37212_1 && git checkout t37212_1Patchset v1 (message #1) is on t37212_1
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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers