Re: Windows locales and tests portability

Hi Andrey,

Thanks, that makes sense.

I agree that fixing the tests independently is reasonable, and that my
patch is a separate behavior change rather than just a test fix.

You're also right about LC_ALL precedence. The patch as posted does
not reproduce POSIX semantics in that respect. If we want to honor
locale environment variables on Windows, it should probably follow the
usual precedence rules rather than applying LC_NUMERIC unconditionally.

The reason I started looking beyond the tests is that I found a
user-visible case as well: with a Windows locale using a comma decimal
separator, psql rejects for example:

\watch 0.01

even when the environment contains LC_NUMERIC=C.

So I still think there is a frontend behavior question worth discussing,
but I agree it should not block an independent test-side fix.

I'll update the discussion in my thread accordingly:

https://www.postgresql.org/message-id/CAJnzarxw2pJjVGQpwosjzBW%2BMO67vqSJt4jjVD5T3GpKpX%2BdkQ%40mail.gmail.com

Thanks!

Best regards,
Andrew

On Tue, Sep 22, 2026 at 2:40 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> Hi Andrew,
>
> On Sep 22, 2026, Andrew Bille wrote:
> > fixing it in frontend locale
> > initialization is preferable to teaching individual tests about
> > Windows decimal separators.
>
> My patch was intended to adapt the tests to the existing Windows
> behavior. Yours changes that behavior for frontend users, which seems
> worth discussing separately. A non-empty LC_NUMERIC may already be
> inherited by scripts that currently work because Windows ignores it.
>
> There is also the precedence question: this patch applies LC_NUMERIC
> without checking LC_ALL, so it does not quite reproduce POSIX behavior.
> I'd propose to fix the tests independently while discussing what locale
> environment handling we want on Windows.
>
> Thank you!
>
>
> Best regards, Andrew Borodin.