Translation of the NextOID message in pg_controldata
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:t253780psql -h localhost -U postgresBuilt from patchset v9 (message #9), September 14, 2026 at 11:14 PM.
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 t253780_9 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 t253780_9 && git checkout t253780_9Patchset v9 (message #9) is on t253780_9
Hello,
Commit cb298616463 changed the following line:
- printf(_("Latest checkpoint's NextOID: %u\n"),
+ printf(_("Latest checkpoint's NextOID: " OID8_FORMAT "\n"),It appears that xgettext does not recognize PostgreSQL's OID8_FORMAT
macro and therefore extracts only the preceding string literal as the
msgid. In contrast, PRIu64, which is used in the same file, is
correctly extracted as %<PRIu64>. Therefore, shouldn't we use "%"
PRIu64 instead of OID8_FORMAT here as well?
I confirmed that, with the attached patch, the complete string is
correctly extracted as the msgid in the PO files. The patch also adds
a comment at the macro definitions noting that *_FORMAT macros cannot
be used directly in translatable messages.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Oops!
At Mon, 14 Sep 2026 12:46:45 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
I confirmed that, with the attached patch, the complete string is
I accidentally attached a broken patch. The attached patch is the
corrected version.
Sorry for the mistake.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
Commit cb298616463 changed the following line:
- printf(_("Latest checkpoint's NextOID: %u\n"), + printf(_("Latest checkpoint's NextOID: " OID8_FORMAT "\n"),
It appears that xgettext does not recognize PostgreSQL's OID8_FORMAT
macro and therefore extracts only the preceding string literal as the
msgid. In contrast, PRIu64, which is used in the same file, is
correctly extracted as %<PRIu64>. Therefore, shouldn't we use "%"
PRIu64 instead of OID8_FORMAT here as well?
That would be fairly sad, because it means hard-wiring the fact that
Oid8 is the same as uint64 in a bunch of non-obvious places.
Admittedly, we've lived with formatting Oid as %u for a long time.
But can we fix this some other way?
regards, tom lane
On Mon, Sep 14, 2026 at 12:32:18AM -0400, Tom Lane wrote:
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
Commit cb298616463 changed the following line:
- printf(_("Latest checkpoint's NextOID: %u\n"), + printf(_("Latest checkpoint's NextOID: " OID8_FORMAT "\n"),
Oops, sorry about that. I can see the breakage with some update-po.
It appears that xgettext does not recognize PostgreSQL's OID8_FORMAT
macro and therefore extracts only the preceding string literal as the
msgid. In contrast, PRIu64, which is used in the same file, is
correctly extracted as %<PRIu64>. Therefore, shouldn't we use "%"
PRIu64 instead of OID8_FORMAT here as well?
Yes, it's not the first time that 64-bit values show this problem with
translatable strings.
That would be fairly sad, because it means hard-wiring the fact that
Oid8 is the same as uint64 in a bunch of non-obvious places.
Admittedly, we've lived with formatting Oid as %u for a long time.
But can we fix this some other way?
The proposed patch to use the Pri markers would work with gettext().
Just note that, I have.. cough.. also broken pg_resetwal in two
places.
The other places switched recently (amcheck, backend) only relate to
internal errors and places without po files, so they're out of the
picture, fine with the OID8_FORMAT markers.
Anyway, I really want to keep this code greppable with the Oid8
markers, so I don't think that the proposed patch is what I would do.
The magic solution I can think of is to remove the markers from the
translatable strings, and replace them with a set of %s, as of the
attached patch, then use a pre-built string that itself uses
OID8_FORMAT. I am pretty sure we have used this method in other
places of the tree, but I cannot pinpoint where, on top of my mind.
The idea of documenting this trick or equivalent in c.h is interesting
in the long term, for sure. Any suggestions how to word this
requirement close to the OID8_FORMAT declaration?
Thoughts?
--
Michael
On 2026-Sep-14, Michael Paquier wrote:
The magic solution I can think of is to remove the markers from the
translatable strings, and replace them with a set of %s, as of the
attached patch, then use a pre-built string that itself uses
OID8_FORMAT. I am pretty sure we have used this method in other
places of the tree, but I cannot pinpoint where, on top of my mind.
Yeah, we used to do that for long long, until we got rid of it using the
%z format instead. I was happy about no longer having that coding
pattern TBH.
I think this change would break what I proposed in
/messages/by-id/202601310924.yoik5n3blgt4@alvherre.pgsql
(FTR I decided to heed Peter's advice and not implement it in the way
proposed there, but instead build some generic facility that can also be
used elsewhere.)
I'm not sure I understand why we care that we hardcode that Oid8 is the
same as uint64. It's never been a problem that Oid is the same as uin32 ...
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)
On Mon, Sep 14, 2026 at 08:41:59AM +0200, Alvaro Herrera wrote:
I'm not sure I understand why we care that we hardcode that Oid8 is the
same as uint64. It's never been a problem that Oid is the same as uin32 ...
For me, the reason is greppability of oid8 information as the
variables printed in the strings may not refer to variables declared
in the code.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Mon, Sep 14, 2026 at 08:41:59AM +0200, Alvaro Herrera wrote:
I'm not sure I understand why we care that we hardcode that Oid8 is the
same as uint64. It's never been a problem that Oid is the same as uin32 ...
For me, the reason is greppability of oid8 information as the
variables printed in the strings may not refer to variables declared
in the code.
Yeah. It's not a big deal, so maybe PRIu64 is the best option.
I just wanted to be sure we'd considered whether there's another way.
regards, tom lane
On 14.09.26 09:08, Michael Paquier wrote:
On Mon, Sep 14, 2026 at 08:41:59AM +0200, Alvaro Herrera wrote:
I'm not sure I understand why we care that we hardcode that Oid8 is the
same as uint64. It's never been a problem that Oid is the same as uin32 ...For me, the reason is greppability of oid8 information as the
variables printed in the strings may not refer to variables declared
in the code.
I don't understand what this means. Do you mean you want to grep for
where an oid8 value is being printed? I mean, that just won't work. We
don't accommodate that in the code for anything else in place of "oid8".
I think the symbol OID8_FORMAT should be purged from the code. Its
presence is just going to cause confusion, with people using it in
incorrect ways, and inviting more XXX_FORMAT symbols to be added. We
have just been working on getting rid of these after all.
On Mon, Sep 14, 2026 at 09:01:27PM +0200, Peter Eisentraut wrote:
I think the symbol OID8_FORMAT should be purged from the code. Its presence
is just going to cause confusion, with people using it in incorrect ways,
and inviting more XXX_FORMAT symbols to be added. We have just been working
on getting rid of these after all.
Okay. The string idea is discarded then, in profit of some PRIu64 in
these three spots.
Perhaps getting rid of OID8_FORMAT entirely is the best thing to do,
as you suggest. The attached does so, better applied down to v19
that's not been released yet. The xlogdesc.c feels slightly weird,
but perhaps that's OK. WDYT?
--
Michael