Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Andrew Dunstan <andrew@dunslane.net>, Tristan Partin <tristan@neon.tech>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-25T00:42:49Z
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 Sat, Nov 23, 2024 at 10:32:31AM +1300, Thomas Munro wrote:
> I realised that there is another aspect to this: it must be impossible
> to build PostgreSQL with the original MinGW/MSYS project by now.  I
> don't understand the history of the MinGW/MinGW-w64 fork, but if
> they're both still live projects out there adding to the general
> confusion about the frankenwindows multiverse, we should clarify our
> situation.  As far as I know, we're only testing the second thing, and
> only the second thing can use UCRT, and only the second thing is a
> viable alternative toolchain for software that is primarily targeting
> current Visual Studio, which I think is something we can say about our
> project.  Right?

FWIW, I am not seeing any advantage in mentioning MinGW at all at this
stage, just extra maintenance burden.  As far as I know, MinGW is a
gcc port that has only a 32b implementation.  MinGW-w64 is built on 
top of it and it includes *both* 32b and 64b implementations, as you
say, with more WIN32 APIs than the former.

So +1 to simplify a bit that stuff.
--
Michael