RE: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607

Thanks, Thomas. Will wait for the build option to do further testing.

Regards!
Haifang

-----Original Message-----
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Sent: Tuesday, June 25, 2024 4:52 AM
To: Haifang Wang (Centific Technologies Inc) <v-haiwang(at)microsoft(dot)com>
Cc: Rahul Pandey <pandeyrah(at)microsoft(dot)com>; Vishwa Deepak <Vishwa(dot)Deepak(at)microsoft(dot)com>; Shawn Steele <Shawn(dot)Steele(at)microsoft(dot)com>; Amy Wishnousky <amyw(at)microsoft(dot)com>; Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>; pgsql-bugs(at)lists(dot)postgresql(dot)org; Shweta Gulati <gulatishweta(at)microsoft(dot)com>; Ashish Nawal <nawalashish(at)microsoft(dot)com>
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607

On Tue, Jun 4, 2024 at 9:22 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Since no one has come forward to test the patch I wrote on Windows, I
> think my next move will be to try to make a build option that can also
> do locale name renaming on Unix, so that I have something that I could
> test myself and push for the next release of PostgreSQL which will be
> in October.

Here is a such a patch. If you go into pg_config_manual.h and uncomment this line:

/* #define DEBUG_SETLOCALE_MAP */

... then Unix systems will also be able to rename locales passed to setlocale(). A map file can be provided either by putting its absolute path into the environment variable PG_SETLOCALE_MAP, or by installing it as $PREFIX/share/postgresql/setlocale.map. I couldn't immediately think of a good way to find it in the data directory.

Here's an example of a line that should fix the Turkish problem (though I haven't tested that, I am not a Windows user):

Turkish_T*.1254=tr-TR.1254

I added some documentation and showed that example.

If you wanted to check it's working on a Unix system, you might try some lines like *.UTF-8=does_not_exist or en_US.UTF-8=fr_FR.UTF-8 and then somehow verify that it's using French.

I considered adding win32setlocale.c to the list of files to build for the port libraries even on Unix, and then wrapping the contents in #ifdef, but IIUC macOS squawks if you have an empty .c after preprocessing, so I'd have to add a dummy symbol in there. Or maybe that'd be better than what I did here, namely including win32setlocale.c in chklocale.c in this case. Better ideas welcome.
Adding a meson/configure switch to enable it and make the whole .c file optional seemed excessive.