Horton

Re: On non-Windows, hard depend on uselocale(3)

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tristan Partin <tristan@neon.tech>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-14T12:53:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert "Tidy up locale thread safety in ECPG library."

  2. Tidy up locale thread safety in ECPG library.

  3. Revert "Blind attempt to fix _configthreadlocale() failures on MinGW."

  4. Require ucrt if using MinGW.

  5. Remove configure check for _configthreadlocale().

  6. Simplify checking for xlocale.h

  7. All supported systems have locale_t.

On 14.11.24 08:48, Thomas Munro wrote:
> The three MinGW environments we test today are using ucrt, and
> configure detects the symbol on all.  Namely: fairwren
> (msys2/mingw64), the CI mingw64 task and the mingw cross-build that
> runs on Linux in the CI CompilerWarnings task.  As far as I know these
> are the reasons for, and mechanism by which, we keep MinGW support
> working.  We have no policy requiring arbitrary old MinGW systems
> work, and we wouldn't know anyway.

Right.  So I think we could unwind this in steps.  First, remove the 
configure test for _configthreadlocale() and all the associated #ifdefs 
in the existing ecpg code.  This seems totally safe, it would just leave 
behind MinGW older than 2016 and MSVC older than 2015, the latter of 
which is already the current threshold.

Then the question whether we want to re-enable the error checking on 
_configthreadlocale() that was reverted by 2cf91ccb, or at least 
something similar.  This should also be okay based on your description 
of the different Windows runtimes.  I think it would also be good to do 
this to make sure this works before we employ _configthreadlocale() in 
higher-stakes situations.

I suggest doing these two steps as separate patches, so this doesn't get 
confused between the various thread-related threads that want to 
variously add or remove uses of this function.