Re: Inconsistent LSN format in pg_waldump output

On 2025-Jul-03, Michael Paquier wrote:

> Yep.  If you do not want this new policy to be forgotten by new paths,
> I'd suggested to standarize that with something like that, close to
> the existing LSN_FORMAT_ARGS():
> #define LSN_FORMAT "%X/%08X"

Well, the reason we didn't use a macro in the format string is that
translatability suffers quite a bit, and it's quite annoying.  You can
still use it in strings that aren't going to be translated -- for
instance in all the xlog *_desc routines, in elog(), errmsg_internal(),
errdetail_internal().  But for translatable messages such as errmsg(),
errdetail, it's going to break.  For example, one particular message in
twophase.c was originally

msgid "could not read two-phase state from WAL at %X/%X"

after this patch, it becomes

msgid "could not read two-phase state from WAL at "

which is obviously broken.  (You can test this by running "make
update-po" and looking at the src/backend/po/*.po.new files.  No idea
hwo to do this under Meson, it doesn't seem documented.)

Eyeballing the patch I think a majority of the messages are not
translatable, so I'm still okay with adding and using the macro.  But we
need a revision to go back to literal %X/%08X in errmsg(), errdetail(),
report_invalid_record().  I'd also add a comment next to the macro
indicating that the macro MUST NOT be used for translatable strings, as
it otherwise results in a bug that's only visible if you're running a
version in a language other than English.  I bet we're still going to
get hackers use it badly, but not often.

The GNU gettext manual suggests you can print the value to a string
variable and then use %s to include that in the translatable string, but
I doubt that's an improvement over just using %X/%08X directly.
Bottom of this page here:
https://www.gnu.org/software/gettext/manual/html_node/No-string-concatenation.html

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/