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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tristan Partin <tristan@neon.tech>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-11-20T00:00:11Z
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 20, 2023 at 11:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > BTW is this comment in snprintf.c true?
>
> >  * 1. No locale support: the radix character is always '.' and the '
> >  * (single quote) format flag is ignored.
>
> > It is in the backend but only because we nail down LC_NUMERIC early
> > on, not because of any property of snprintf.c, no?
>
> Hmm, the second part of it is true.  But given that we punt float
> formatting to libc, I think you are right that the first part
> depends on LC_NUMERIC being frozen.

If we are sure that we'll *never* want locale-aware printf-family
functions (ie we *always* want "C" locale), then in the thought
experiment above where I suggested we supply replacement _l()
functions, we could just skip that for the printf family, but make
that above comment actually true.  Perhaps with Ryu, but otherwise by
punting to libc _l() or uselocale() save/restore.