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-21T07:38:08Z
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 20.11.24 10:00, Thomas Munro wrote:
> On Fri, Nov 15, 2024 at 1:53 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> 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.
> 
> OK, do you think these three patches tell the _configthreadlocale()
> story properly?  (Then after that we can get back to getting rid of
> it...)

Yes, this is very clear and helpful.  Thanks.