Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows

Bryan Green <dbryan(dot)green(at)gmail(dot)com> writes:
> On 12/11/2025 8:43 AM, Peter Eisentraut wrote:
>> I wonder, this change that gettext did with the locale naming, does that
>> also affect what guidance we need to provide to users about how to
>> configure locale names?  For example, on a Unix-ish system, a user can
>> do something like initdb ... --lc-messages=de_DE.  What locale name
>> format do you need to use on Windows to get the translations to
>> activate?  Does this also depend on the gettext version?

> If the language catalogue is installed then they will get translated
> messages as expected. The downside is that because they are passing a
> posix locale name then gettext will still do the enumeration everytime.
> This will have the negative performance impact. The good news is that
> gettext has accepted my cache patch for their next release. If a
> Windows system is configured with lc_messages="de_DE", but has the next
> release of gettext-- they should be fine. If they don't have the next
> release of gettext-- they will notice the performance issue, but that
> can be fixed by just changing to from "de_DE" to the correct Windows
> locale name.

So IIUC, POSIX-style lc_messages settings do still work on Windows and
will continue to do so, they just incur some extra overhead with
current gettext versions?

If that's the case, I'm inclined to leave my NLS-testing patch [1] as-is,
unconditionally setting a POSIX lc_messages value. I had anticipated
adding some logic to it to select a Windows locale name when on
Windows, but that seems rather messy, and it's not even clear that the
test would net out faster. It only needs to do a dozen or so message
lookups, which has to be set against the time needed to identify what
platform we are running on.

regards, tom lane

[1] https://www.postgresql.org/message-id/1038674.1765568967%40sss.pgh.pa.us