Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: Remaining dependency on setlocale()
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Jeff Davis" <pgsql@j-davis.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
 Peter Eisentraut
 <peter@eisentraut.org>,
 Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers@postgresql.org
In-Reply-To: <a1a184524e11bb4dc8092353a02672cc42a05233.camel@j-davis.com>
Date: Mon, 03 Nov 2025 20:14:03 +0100
Message-Id: <5e709c7a-0504-426c-8a7d-e0701c334cd7@manitou-mail.org>
Archived-At: 
 <https://www.postgresql.org/message-id/5e709c7a-0504-426c-8a7d-e0701c334cd7%40manitou-mail.org>
Precedence: bulk

	Jeff Davis wrote:

> > > Extensions often need to be updated for a new major version.
> >=20
> > I think forcing the C locale is not comparable to API changes,
> > and the consequences are not even necessarily fixable for extensions.
>=20
> Are we in agreement that it's fine for C extensions?

No, I think we should put the database's lc_ctype
into LC_CTYPE and the database's lc_collate into
LC_COLLATE, independently of anything else,
like it was done until commit 5e6e42e.
I believe that's the purpose of these database
properties, whether the provider is libc or ICU or builtin.

Forcing "C" is a disruptive change, that IMO does
not seem compensated by substantial advantages
that would justify the disruption.


> > CREATE FUNCTION lt_test(text,text) RETURNS boolean as $$
> >  use locale; return ($_[0] lt $_[1])?1:0;
> > $$ LANGUAGE plperlu;
> >=20
> > select lt_test('a', 'B');
>=20
> Are you aware of PL code that does things like that? If the database
> locale is ICU, that would be at least a little bit confusing.

plperl users writing "use locale" should understand that
it's the libc locale, like when this code is run outside Postgres.


Best regards,
--=20
Daniel V=E9rit=E9=20
https://postgresql.verite.pro/