Re: On non-Windows, hard depend on uselocale(3)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: "Tristan Partin" <tristan@neon.tech>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>
Date: 2023-11-15T19:04:03Z
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
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> "Tristan Partin" <tristan@neon.tech> writes: >>> I would like to propose removing HAVE_USELOCALE, and just have WIN32, >>> which means that Postgres would require uselocale(3) on anything that >>> isn't WIN32. >> You would need to do some research and try to prove that that won't >> be a problem on any modern platform. Presumably it once was a problem, >> or we'd not have bothered with a configure check. > For reference, the Perl effort to use the POSIX.1-2008 thread-safe > locale APIs have revealed several platform-specific bugs that cause it > to disable them on FreeBSD and macOS: > https://github.com/perl/perl5/commit/9cbc12c368981c56d4d8e40cc9417ac26bec2c35 > https://github.com/perl/perl5/commit/dd4eb78c55aab441aec1639b1dd49f88bd960831 > and work around bugs on others (e.g. OpenBSD): > https://github.com/perl/perl5/commit/0f3830f3997cf7ef1531bad26d2e0f13220dd862 > But Perl actually makes use of per-thread locales, because it has a > separate interpereer per thread, each of which can have a different > locale active. Since Postgres isn't actually multi-threaded (yet), > these concerns might not apply to the same degree. Interesting. That need not stop us from dropping the configure check for uselocale(), but it might be a problem for Tristan's larger ambitions. regards, tom lane