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.
