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

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>

To: Peter Eisentraut <peter@eisentraut.org>

Cc: Tristan Partin <tristan@neon.tech>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2024-11-20T09:00:13Z

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 →

Revert "Tidy up locale thread safety in ECPG library."
- 3c8e463b0d88 18.0 landed
Tidy up locale thread safety in ECPG library.
- 8e993bff5326 18.0 landed
Revert "Blind attempt to fix _configthreadlocale() failures on MinGW."
- a62d90f2e5cb 18.0 landed
Require ucrt if using MinGW.
- 1758d4244616 18.0 landed
Remove configure check for _configthreadlocale().
- f1da075d9a03 18.0 landed
Simplify checking for xlocale.h
- 9c2a6c5a5f4b 18.0 landed
All supported systems have locale_t.
- 8d9a9f034e92 17.0 cited

Attachments

0001-Remove-configure-check-for-_configthreadlocale.patch (application/octet-stream) patch 0001
0002-Formally-require-ucrt-on-Windows.patch (application/octet-stream) patch 0002
0003-Revert-Blind-attempt-to-fix-_configthreadlocale-fail.patch (application/octet-stream) patch 0003

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...)