On Fri, Dec 13, 2024 at 8:22 AM Jeff Davis <pg...@j-davis.com> wrote: > On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote: > > 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. > > Did we reach a conclusion here? Any thoughts on moving in this > direction, and whether 18 is the right time to do it?
I think this is the best way, and I haven't seen anyone supporting any other idea. (I'm working on those setlocale()-removal patches I mentioned, more very soon...)
