Re: Remaining dependency on setlocale()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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-12 18:41:58
Message-ID: 215d5fa1-49c7-487c-a6be-e772c0b46805@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.11.25 20:14, Daniel Verite wrote:
> 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.

From my perspective, the difference between LC_COLLATE and LC_CTYPE is
that LC_COLLATE has a quite limited impact area. Either your code uses
strcoll() (or strxfrm()) or it does not. And if it does, you can find
all the places and adjust them, and it probably won't be that many
places. The impact area of LC_CTYPE is much larger and more complicated
and possibly interacts with other settings and third-party libraries in
ways that we don't understand yet and might not be able to change.
That's why I'm more hesitant about it. But I don't see any reason to
keep LC_COLLATE set going forward.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-11-12 18:59:33 Re: Remaining dependency on setlocale()
Previous Message Andres Freund 2025-11-12 18:37:40 Re: Support a`--with-copy-program` compile flag