[PATCH] Honor LC_NUMERIC environment variable on Windows - Mailing list pgsql-hackers

Hi,

While running the TAP tests on Windows with the system locale set to
Russian, I found that frontend programs don't honor LC_NUMERIC from the
environment.

PostgreSQL::Test::Utils explicitly sets:

    $ENV{LC_NUMERIC} = 'C';

but pg_test_timing still produces output such as:

    Average loop time including overhead: 21,30 ns
    Observed timing durations up to 99,9900%:

instead of using a dot as the decimal separator.

This is not specific to pg_test_timing.  For example, psql also fails to
parse decimal arguments such as:

    \watch 0.01

when the Windows user locale uses a comma as the decimal separator.

I reduced this to the behavior of the Windows CRT.  With the environment:

    LANG=C
    LC_ALL=C
    LC_NUMERIC=C

a small MSVC test program shows that:

    setlocale(LC_ALL, "");

selects the Windows user locale (Russian_Russia.1251), with "," as the
decimal separator.  Calling:

    setlocale(LC_NUMERIC, "C");

explicitly afterwards restores the expected "." separator.

For comparison, on Linux I checked the locale selection behavior:

    LANG=C                                      -> "."
    LANG=C, LC_NUMERIC=ru_RU.UTF-8             -> ","
    LC_ALL=C, LC_NUMERIC=ru_RU.UTF-8           -> "."
    LANG=C, LC_NUMERIC=""                       -> "."

The attached patch keeps the existing Windows behavior when LC_NUMERIC
is unset or empty, but explicitly applies a non-empty LC_NUMERIC
environment setting after setlocale(LC_ALL, "").

With the patch, pg_test_timing uses "." when LC_NUMERIC=C, and psql
correctly accepts decimal \watch intervals under a Russian Windows
system locale.

Tested on PostgreSQL master (20devel), Windows 11, MSVC 19.44.

Regards,
Andrew