Re: Remaining dependency on setlocale()

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remaining dependency on setlocale()
Date: 2025-11-03 19:14:03
Message-ID: 5e709c7a-0504-426c-8a7d-e0701c334cd7@manitou-mail.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis wrote:

> > > Extensions often need to be updated for a new major version.
> >
> > I think forcing the C locale is not comparable to API changes,
> > and the consequences are not even necessarily fixable for extensions.
>
> 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;
> >
> > select lt_test('a', 'B');
>
> 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,
--
Daniel Vérité
https://postgresql.verite.pro/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-11-03 19:15:59 Re: MSVC: Improve warning options set
Previous Message Peter Eisentraut 2025-11-03 18:56:16 Re: MSVC: Improve warning options set