On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
> 1. The process global locale is always "C". If you ever call
> uselocale(), it can only be for short stretches, and you have to
> restore it straight after; perhaps it is only ever used in
> replacement
> _l() functions for systems that lack them. You need to use _l()
> functions for all non-"C" locales. The current database default
> needs
> to be available as a variable (in future: thread-local variable, or
> reachable from one), so you can use it in _l() functions. The "C"
> locale can be accessed implicitly with non-l() functions, or you
> could
> ban those to reduce confusion and use foo_l(..., LC_GLOBAL_LOCALE)
> for
> "C". Or a name like PG_C_LOCALE, which, in backend code could be
> just
> LC_GLOBAL_LOCALE, while in frontend/library code it could be the
> singleton mechanism I showed in CF#5166.
+1 to this approach. It makes things more consistent across platforms
and avoids surprising dependencies on the global setting.
We'll have to be careful that each call site is either OK with C, or
that it gets changed to an _l() variant. We also have to be careful
about extensions.
Regards,
Jeff Davis
