| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tristan Partin <tristan(at)neon(dot)tech>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: On non-Windows, hard depend on uselocale(3) |
| Date: | 2023-11-20 00:00:11 |
| Message-ID: | CA+hUKG+YxfUyUOY7OHUFCgenAgq9znksd=Z+vyb20KHG=2iAnw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 20, 2023 at 11:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-11-20 01:15:49 | Re: Add recovery to pg_control and remove backup_label |
| Previous Message | Michael Paquier | 2023-11-19 23:56:58 | Re: pg_upgrade and logical replication |