Re: Let's add a test for NLS translation of PRI* macros

Bryan Green <dbryan.green@gmail.com> writes:
> On 12/8/2025 1:23 PM, Tom Lane wrote:
>> I don't know whether the attached will pass on Windows: we might
>> not be able to assume that "es_ES" is the right LC_MESSAGES
>> setting to use.  But it works for me on Linux.

> gettext() will be fine with that if you are using < 0.20.  After that
> version it expects you to send it the windows locale, not the
> IsoLocalName() converted one-- it will fail to find "es-ES" (by
> enumerating through ~259 window locales) and use a fallback to translate
> messages.  Since gettext() will not cache the "not found" locale, the
> expensive enumeration call will happen everytime [1].  I am in the
> middle of writing some patches to take care of that problem and a couple
> of others involving that area of the code and gettext().

Cool; we'll worry about that later then.  In the meantime, the
cfbot discovered two other problems with this patch:

1. FreeBSD and NetBSD don't like "es_ES" either: they want a codeset
specification appended, and it had better be spelled just so
(eg, "UTF-8" not "utf-8" or "utf8").

2. FreeBSD and macOS translate PRIdMAX as "jd" which causes our
snprintf.c to spit up.  We might have noticed this earlier, but
the only use of PRI?MAX in our tree at the moment is in zic.c's
error reports, a code path we don't ordinarily exercise.

v4-0001 attached tries to deal with #1 by extracting a codeset
name from pg_database.datctype. That seems to work for me locally,
but I'll be interested to see what cfbot thinks.

v4-0002 attached deals with #2 by making snprintf.c support the "j"
width modifier, as required by POSIX for years now.  We'd likely
have had to do that at some point anyway, so might as well be now.

(0002 probably ought to get committed first, but I wrote them
in this order so here they are.)

			regards, tom lane