Date: Wed, 26 Aug 2026 16:25:34 -0700
From: Noah Misch <noah@leadboat.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Daniel Verite <daniel@manitou-mail.org>,
	Thomas Munro <thomas.munro@gmail.com>,
	Peter Eisentraut <peter@eisentraut.org>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: Remaining dependency on setlocale()
Message-ID: <20260826232534.13.noahmisch@microsoft.com>
References: <5e709c7a-0504-426c-8a7d-e0701c334cd7@manitou-mail.org>
 <36dc305c6445970f7680dbba63cf9b32a5e91d27.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <36dc305c6445970f7680dbba63cf9b32a5e91d27.camel@j-davis.com>
User-Agent: Mutt/2.3.0 (2026-01-25)
Archived-At: 
 <https://www.postgresql.org/message-id/20260826232534.13.noahmisch%40microsoft.com>
Precedence: bulk

On Mon, Nov 03, 2025 at 11:59:57AM -0800, Jeff Davis wrote:
> On Mon, 2025-11-03 at 20:14 +0100, 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.
> 
> Is there a clean way to document this behavior? I have tried to improve
> the documentation in this area before, but it's not easy because the
> behavior is so nuanced.

While documenting it is feasible, documentation is a poor replacement for
retaining longstanding and useful behavior.

> Reverting commit 5e6e42e may be the right thing, but I'd like to hear
> what others have to say on this point first.

I think a revert would be the better thing.  The stated reason for the commit
was "avoid accidentally depending on libc behavior when using a different
provider".  Such an accident gets LANG=C behavior, but that's still easy to
miss.  The accident remains silent.  To achieve your reasonable goal of
detecting such accidents, I'd prefer something more like a test with an
LD_PRELOAD DSO that poisons setlocale-dependent functions to elog or abort().

If nothing else, the release notes would need to mention this commit.

> In particualr, I'd like to
> know whether such a revert is based on principle, a practical problem,
> or just an abundance of caution.

In this taxonomy, I would call it an abundance of caution, combined with
commit 5e6e42e not moving the needle much toward its goal of avoiding
accidents.  In other words, I agree with this:

On Mon, Nov 03, 2025 at 08:14:03PM +0100, Daniel Verite wrote:
> Forcing "C" is a disruptive change, that IMO does
> not seem compensated by substantial advantages
> that would justify the disruption.

Also important to me: the disruption is silent.  Applications are on their own
to even figure out the change affected them.

On Mon, Nov 10, 2025 at 12:39:28PM -0800, Jeff Davis wrote:
> On Mon, 2025-11-03 at 20:14 +0100, 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.
> 
> As phrased, that appears to be a promise that we will never support
> thread-per-connection. setlocale() is not thread-safe, and uselocale()
> is not available on NetBSD.

That's one way to harmonize Daniel's vision with NetBSD, but I wouldn't do it
that way.  NetBSD has chosen not to implement this POSIX-defined interface.
PostgreSQL should confine the consequences of NetBSD's decision to NetBSD, not
treat it as a constraint on PostgreSQL elsewhere.  For thread-per-connection,
I'd likely just document that uselocale()-lacking systems leave all threads at
the postmaster's setlocale(LC_ALL, "") and that it's intended to be noticeable
only in non-PostgreSQL code like Perl.