On Fri, Jul 11, 2025 at 6:33 AM Jeff Davis <pgsql@j-davis.com> wrote:
> On Thu, 2025-07-10 at 12:01 +1200, Thomas Munro wrote:
> > I tried to make a portable PG_C_LOCALE mechanism like that, but it
> > was
> > reverted for reasons needing more investigation... see
> > 8e993bff5326b00ced137c837fce7cd1e0ecae14 (reverted by
> > 3c8e463b0d885e0d976f6a13a1fb78187b25c86f).
>
> The revert seems to be related to pgport_shlib. At least for my current
> work, I'm focused on removing setlocale() dependencies in the backend,
> and a PG_C_LOCALE should work fine there.
OK, I'll figure out what happened with that and try to post a new
version over on that other thread soon.
(FWIW I learned a couple of encouraging things about that topic:
glibc's newlocale(LC_ALL, NULL, 0) seems to give you a static
singleton anyway, no allocation happens, so it can't fail in practice
and it's cheap, and FreeBSD also supports LC_C_LOCALE like NetBSD and
macOS, it just doesn't have a name, you pass NULL instead (which is
the value that LC_C_LOCALE has on those other systems). I actually
rather like the macro, because how else are you supposed to test
whether this system can accept NULL there?)
