From 74592b796d87e369e8f35d06e880e271a2ea4648 Mon Sep 17 00:00:00 2001 From: Andrew Bille Date: Mon, 21 Sep 2026 09:36:06 +0300 Subject: [PATCH] Honor LC_NUMERIC environment variable on Windows The Windows CRT does not honor the LC_NUMERIC environment variable when setlocale(LC_ALL, "") is called. Instead, LC_NUMERIC is initialized from the Windows user locale. This differs from POSIX behavior and can cause frontend programs to use an unexpected decimal separator even when LC_NUMERIC has been explicitly set. In particular, PostgreSQL TAP tests set LC_NUMERIC=C, but Windows frontend programs can still format and parse numbers using the system locale. After initializing the locale normally, explicitly apply a non-empty LC_NUMERIC environment setting on Windows. --- src/common/exec.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/common/exec.c b/src/common/exec.c index 2881aa92ca6..45957b7a721 100644 --- a/src/common/exec.c +++ b/src/common/exec.c @@ -437,6 +437,21 @@ set_pglocale_pgservice(const char *argv0, const char *app) { setlocale(LC_ALL, ""); +#ifdef WIN32 + /* + * Unlike POSIX implementations, the Windows CRT does not honor + * LC_NUMERIC from the environment when setlocale() is called with + * an empty locale name. Apply an explicitly specified LC_NUMERIC + * setting separately. + */ + { + const char *lc_numeric = getenv("LC_NUMERIC"); + + if (lc_numeric != NULL && lc_numeric[0] != '\0') + setlocale(LC_NUMERIC, lc_numeric); + } +#endif + /* * One could make a case for reproducing here PostmasterMain()'s test * for whether the process is multithreaded. Unlike the postmaster, -- 2.55.0.windows.3