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

=?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