Re: Remaining dependency on setlocale()

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: 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-10-31 19:59:20
Message-ID: 09ca947879d178f35d6765c70095733810a4c3c0.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-10-31 20:03:14 Re: POC: Parallel processing of indexes in autovacuum
Previous Message Tom Lane 2025-10-31 19:48:14 Re: contrib/sepgsql regression tests have been broken for months