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

Thomas Munro <thomas.munro@gmail.com>

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

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Tristan Partin <tristan@neon.tech>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2024-08-10T03:48:45Z

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

v3-0001-Improve-locale-thread-safety-of-ECPG.patch (application/octet-stream) patch v3-0001

On Sat, Aug 10, 2024 at 1:29 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Here is a new attempt at this can of portability worms.

Slightly better version:

* it's OK to keep relying on the global locale in the backend; for
now, we know that LC_NUMERIC is set in main(), and in the
multi-threaded future calling setlocale() even transiently will be
banned, so it seems it'll be OK to just keep doing that, right?

* we could use LC_C_LOCALE to get a "C" locale slightly more
efficiently on those; we could define it ourselves for other systems,
using pg_get_c_locale()