Message-ID: <fa04b56430fa4b5da7311c2faa113f406c6d192a.camel@j-davis.com>
Subject: Re: Remaining dependency on setlocale()
From: Jeff Davis <pgsql@j-davis.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: Thu, 12 Dec 2024 11:22:09 -0800
In-Reply-To: <b19ea499a6d78c101dc55b61bfb42069b427445c.camel@j-davis.com>
References: <4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel@j-davis.com>
	 <1841102.1722982989@sss.pgh.pa.us>
	 <CA+hUKGK7qKDHgoh1HuvMhtcpAwwVBA5BDt33vCzYYqCLfQTtzw@mail.gmail.com>
	 <CA+hUKGLLTy155HTQ6HfHu5-XPNfoFgDsRVUWevj+O6p3UmvPkg@mail.gmail.com>
	 <a70d3db4b8291b61c6937c0c003aa70e2d2c3a9a.camel@j-davis.com>
	 <CA+hUKGL82jG2PdgfQtwWG+_51TQ--6M9XNa3rtt7ub+S3Pmfsw@mail.gmail.com>
	 <b19ea499a6d78c101dc55b61bfb42069b427445c.camel@j-davis.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/fa04b56430fa4b5da7311c2faa113f406c6d192a.camel%40j-davis.com>
Precedence: bulk

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.=C2=A0 The process global locale is always "C".=C2=A0 If you ever cal=
l
> > 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.=C2=A0 You need to use _l()
> > functions for all non-"C" locales.=C2=A0 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.=C2=A0 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".=C2=A0 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.
>=20
> +1 to this approach. It makes things more consistent across platforms
> and avoids surprising dependencies on the global setting.
>=20
> 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