Re: postgresql encoding/locale issues

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, Apr 16, 2023 at 11:07:35AM -0400, Greg Troxel wrote:
> mlelstv%serpens.de@localhost (Michael van Elst) writes:
> 
> > LANG is the default, that gets overridden by LC_* for specific
> > categories.
> >
> > LC_ALL overrides everything, so that's mostly used to turn off locale
> > support for specific commands (e.g. LC_ALL=C awk ...).
> >
> >
> > Postgresql uses LC_CTYPE and LC_COLLATE.
> >
> > Unfortunately we do not support LC_COLLATE (other than "C"), so any
> > setting to a different value (i.e. via LANG or LC_ALL or LC_COLLATE)
> > makes Postgres fail.
> >
> > Setting LANG and overriding LC_COLLATE with "C" works.
> 
> So is it a bug in NetBSD that asking for LC_COLLATE when LANG is set
> leads to getting the LANG value rather than C?  locale(1) doesn't do
> this, but it seems pgsql must be getting back a bad value?

It's not really a bug.

NetBSD correctly handles the logic for these environment variables
and also fails correctly the setlocale(LC_COLLATE, ) call for an
unsupported value.

Postgres correctly fails when it cannot set LC_COLLATE.


We need to implement LC_COLLATE. Could be a trivial version
that just sorts by character code (like "C") with support
for UTF-8 encoding. Or you need to decide on how to sort.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."