Message-ID: <c6379076-aabc-4ee8-920b-bd0d18bd2379@gmail.com>
Date: Mon, 15 Dec 2025 11:24:34 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: PRI?64 vs Visual Studio (2022)
To: pgsql-hackers@lists.postgresql.org
References: <20250331.152829.1921392690375275165.horikyota.ntt@gmail.com>
 <001bdc3b-ef94-4f24-b017-ac8ff0a2ea55@eisentraut.org>
 <CA+hUKGJnmzTqiODmTjf-23yZ=E3HXqFTtKoyp3TF-MpB93hTMQ@mail.gmail.com>
 <1372793.1763519315@sss.pgh.pa.us>
 <CA+hUKGLzXzQcbjEHW08Z6g=mzBkpLtzSJ7Bt2S2XmxP1bwpq8A@mail.gmail.com>
 <1377512.1763522154@sss.pgh.pa.us>
 <e7b902aa-98ac-4d35-bae3-d7d282a938c2@eisentraut.org>
 <1462038.1763567038@sss.pgh.pa.us>
 <CA+hUKG+nMv9bmOcARaDFC6rG=SGWC=TwWSRLrxi29oGeRNKemg@mail.gmail.com>
 <1881391.1765782112@sss.pgh.pa.us>
 <CA+hUKGJaX3AcuKSdEUOZiWc+mzL=+dvGnbMqCvWGY22y6oh9Nw@mail.gmail.com>
 <1991599.1765818338@sss.pgh.pa.us>
Content-Language: en-US
From: Bryan Green <dbryan.green@gmail.com>
In-Reply-To: <1991599.1765818338@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c6379076-aabc-4ee8-920b-bd0d18bd2379%40gmail.com>
Precedence: bulk

On 12/15/2025 11:05 AM, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
>> On Mon, Dec 15, 2025 at 8:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> What to do now?  I could revert 8c498479d and followups, but
>>> I sure don't want to.  A stopgap measure to make the farm look
>>> green would be to add a variant expected-file that accepts
>>> this output, but yech.  Thoughts?
> 
>> So close yet so far... I tried asking if it's easy to fix:
> 
>> https://github.com/sabotage-linux/gettext-tiny/issues/76
> 
> Hmm, not sure if you found the live upstream for that project, but if
> you did, this code hasn't been touched since 2019.  Think we shouldn't
> hold our breath for a fix :-(.  I will go add another expected-file.
> 
> I'm also thinking that maybe we should expand the ambition of that
> test script a little.  Instead of only checking the behavior of PRI*
> when we can test translation, why not run the ereport's all the time?
> This would at least test that <inttypes.h> is sane and snprintf.c
> agrees with it, which we now know is something worth checking.  That's
> colored by seeing that less than half of the buildfarm is finding any
> variant of es_ES to test in.  That's not great, but I'm not seeing
> anything to be done about it.  The only locale names we can be sure
> will be accepted are C/POSIX, and I'd expect gettext() to
> short-circuit that case and not look for a translation.  I'm thinking
> though that it's still worth checking that the untranslated string is
> processed correctly.
> 
> 			regards, tom lane
> 
> 
The GNU gettext implementation does not short-circuit that.  It still
goes through the path of trying to find the message catalogue, it fails,
there is no fallback, messages are untranslated. This is true on Windows
as well as Linux.  Windows just has the curse of an expensive call to
enumerate the locales to find the passed in locale every single time
because of the failure to cache the unfound case.

-- 
Bryan Green
EDB: https://www.enterprisedb.com