Re: Remaining dependency on setlocale() - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Remaining dependency on setlocale()
Date
Msg-id 09ca947879d178f35d6765c70095733810a4c3c0.camel@j-davis.com
Whole thread Raw
In response to Re: Remaining dependency on setlocale()  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Fri, 2025-10-31 at 10:40 +0100, Peter Eisentraut wrote:

> But I'm not sure that we actually want to make that switch.  It would
> be
> good if our code is independent of the global locale settings, but
> that
> doesn't mean that there couldn't be code in extensions, other
> libraries,
> or other corners of the operating system that relies on this.

This question has been brewing for a while. How should we make this
decision?

>   In
> general, and I haven't looked this up in the applicable standards, it
> seems like a good idea to accurately declare what encoding you
> operate in.

One frustration (for me, at least) is that there is no way to set the
encoding without specifying the locale. LC_CTYPE=C.UTF-8 is close, but
the libc version is not available on all platforms and has some quirks.

That makes any changes to the initdb default logic difficult to sort
out. Some combinations which seem simple -- like ICU/UTF8 -- need to
handle the case when LC_CTYPE is not compatible with UTF-8, even though
the LC_CTYPE has no effect in that case.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: contrib/sepgsql regression tests have been broken for months
Next
From: Masahiko Sawada
Date:
Subject: Re: POC: Parallel processing of indexes in autovacuum