On 13.12.24 10:44, Thomas Munro wrote:
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...)

I also think this is the right direction, and we'll get closer with the remaining patches that Thomas has lined up.

I think at this point, we could already remove all locale settings related to LC_COLLATE. Nothing uses that anymore.

I think we will need to keep the global LC_CTYPE setting set to something useful, for example so that system error messages come out in the right encoding.

But I'm concerned about the the Perl_setlocale() dance in plperl.c. Perl apparently does a setlocale(LC_ALL, "") during startup, and that code is a workaround to reset everything back afterwards. We need to be careful not to break that.

(Perl has fixed that in 5.19, but the fix requires that you set another environment variable before launching Perl, which you can't do in a threaded system, so we'd probably need another fix eventually. See <https://github.com/Perl/perl5/issues/8274>.)



Reply via email to