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: Thomas Munro <thomas.munro@gmail.com>

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

Date: 2023-11-15T21:17:08Z

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

Thomas Munro <thomas.munro@gmail.com> writes:
> Currently pg_locale.c requires systems to have *either* uselocale() or
> mbstowcs_l()/wcstombs_l(), but NetBSD satisfies the second
> requirement.

Check.

> The other uses of uselocale() are in ECPG code that must
> be falling back to the setlocale() path.  In other words, isn't it the
> case that we don't require uselocale() to compile ECPG stuff, but it'll
> probably crash or corrupt itself or give wrong answers if you push it
> on NetBSD, so... uhh, really we do require it?

Dunno.  mamba is getting through the ecpg regression tests okay,
but we all know that doesn't prove a lot.  (AFAICS, ecpg only
cares about this to the extent of not wanting an LC_NUMERIC
locale where the decimal point isn't '.'.  I'm not sure that
NetBSD supports any such locale anyway --- I think they're like
OpenBSD in having only pro-forma locale support.)

			regards, tom lane