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

On Tue, Jun 4, 2024 at 9:22 AM Thomas Munro <thomas.munro@gmail.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.