[Noah Misch <noah@leadboat.com>]

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.