public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jeff Davis <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Remaining dependency on setlocale()
Date: Thu, 12 Dec 2024 11:22:09 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CA+hUKGK7qKDHgoh1HuvMhtcpAwwVBA5BDt33vCzYYqCLfQTtzw@mail.gmail.com>
	<CA+hUKGLLTy155HTQ6HfHu5-XPNfoFgDsRVUWevj+O6p3UmvPkg@mail.gmail.com>
	<[email protected]>
	<CA+hUKGL82jG2PdgfQtwWG+_51TQ--6M9XNa3rtt7ub+S3Pmfsw@mail.gmail.com>
	<[email protected]>

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?

Regards,
	Jeff Davis








view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Remaining dependency on setlocale()
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox