On Fri, Jul 11, 2025 at 6:33 AM Jeff Davis <pg...@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?)
