Horton

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

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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:57:41Z
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 Mon, Nov 25, 2024 at 1:43 PM Michael Paquier <michael@paquier.xyz> wrote:
> 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.

Thanks.  I'm going to have a go at adjusting the docs myself so I can
get this committed.  Invitation remains open for someone closer to the
topic to rewrite in a later commit as required for maximum utility to
the reader (I'm never going to install MSYS2, or Windows, I just want
to blow away as much dead code as possible here as it's in the way of
multithreading and other modernisation projects).