Re: On non-Windows, hard depend on uselocale(3)
От | Thomas Munro |
---|---|
Тема | Re: On non-Windows, hard depend on uselocale(3) |
Дата | |
Msg-id | CA+hUKG+YxfUyUOY7OHUFCgenAgq9znksd=Z+vyb20KHG=2iAnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On non-Windows, hard depend on uselocale(3) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: On non-Windows, hard depend on uselocale(3)
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: