Message-ID: <d78d6b0f539460d4d01a869b05fd487cd12cf6a3.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: Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@postgresql.org
Date: Thu, 30 Oct 2025 10:17:03 -0700
In-Reply-To: <d9657a6e51aa20702447bb2386b32fea6218670f.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>
	 <fa04b56430fa4b5da7311c2faa113f406c6d192a.camel@j-davis.com>
	 <CA+hUKGKcS-Zhi8Ud+tv2TanzXBQjH+WsLyPY9DUDXob5VoYAtg@mail.gmail.com>
	 <cd3517c7-ddb8-454e-9dd5-70e3d84ff6a2@eisentraut.org>
	 <d2e7d63c0cc98f425652527cf260a3e6da17d2b0.camel@j-davis.com>
	 <a1396f17f462ee6561820f755caaf2d12eb9fd15.camel@j-davis.com>
	 <9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org>
	 <a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com>
	 <6956823dd669abc64183fc91e64dc2e56e31f3ea.camel@j-davis.com>
	 <ed394f839d813762ddcd65cfcab0e062f8b5e0b1.camel@j-davis.com>
	 <CA+hUKGLYcbnHBXhHk_OFwZ03LE+D=cAirm7TVN8fMhT9rgcTbA@mail.gmail.com>
	 <f040113cf384ada69558ec004a04a3ddb3e40a26.camel@j-davis.com>
	 <CA+hUKGJxSDFcTZSGi++PTC=jM49q1oK=v7Lcdf96VQXXvLhoow@mail.gmail.com>
	 <cdd20efc0f5418c597791a1e3a5abb68fa3ce35b.camel@j-davis.com>
	 <d9657a6e51aa20702447bb2386b32fea6218670f.camel@j-davis.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/d78d6b0f539460d4d01a869b05fd487cd12cf6a3.camel%40j-davis.com>
Precedence: bulk

On Tue, 2025-10-28 at 17:19 -0700, Jeff Davis wrote:
> Attached a new patch series, v6.

I'm eager to start committing this series so that we have plenty of
time to sort out any problems. I welcome feedback before or after
commit, and I can revert if necessary.

The goal here is to do a permanent:

   setlocale(LC_CTYPE, "C")

in the postmaster, and instead use _l() variants where necessary.

Forcing the global LC_CTYPE to C will avoid platform-specific nuances
spread throughout the code, and prevent new code from accidentally
depending on platform-specific libc behavior. Instead, libc ctype
behavior will only happen through a pg_locale_t object.

It also takes us a step closer to thread safety.

LC_COLLATE was already permenently set to "C" (5e6e42e4), and most of
LC_CTYPE behavior already uses a pg_locale_t object. This series is
about removing the last few places that rely on raw calls to
tolower()/toupper() (sometimes through pg_tolower()). Where there isn't
a pg_locale_t immediately available it uses the database default locale
(which might or might not be libc).

There's another thread for what to do about strerror_r[1], which
depends on LC_CTYPE for the encoding:

https://www.postgresql.org/message-id/90f176c5b85b9da26a3265b2630ece3552068=
566.camel@j-davis.com

pg_localeconv_r() does depend on the LC_CTYPE for the encoding, but it
already sets it from lc_monetary and lc_numeric, without using datctype
or the global setting. Then PGLC_localeconv() converts to the database
encoding, if necessary. So it's an exception to the rule that all ctype
behavior goes through a pg_locale_t, but it's not a problem. (Aside: we
could consider this approach as a narrower fix for strerror_r(), as
well.)

There may be a loose end around plperl, as well, but not sure if this
will make it any worse.

Some other LC_* settings still rely on setlocale(), which can be
considered separately unless there's some interaction that I missed.

Note that the datcollate and datctype fields are already mostly
irrelevant for non-libc providers. We could set those to NULL, but for
now I don't intend to do that.

Regards,
	Jeff Davis