Re: Order changes in PG16 since ICU introduction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Order changes in PG16 since ICU introduction
Date
Msg-id 3369718.1682100417@sss.pgh.pa.us
Whole thread Raw
In response to Re: Order changes in PG16 since ICU introduction  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Order changes in PG16 since ICU introduction
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Peter" == Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>  Peter> If the database is created with locale provider ICU, then
>  Peter> lc_collate does not apply here,

> Having lc_collate return a value which is silently being ignored seems
> to me rather hugely confusing.

It's not *completely* ignored --- there are bits of code that are not
yet ICU-ified and will still use the libc facilities.  So we can't
get rid of those options yet, even in an ICU-based database.

> Also, somewhere along the line someone broke initdb --no-locale, which
> should result in C locale being the default everywhere, but when I just
> tested it it picked 'en' for an ICU locale, which is not the right
> thing.

Confirmed:

$ LANG=en_US.utf8 initdb --no-locale
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

Using default ICU locale "en_US".
Using language tag "en-US" for ICU locale "en_US".
The database cluster will be initialized with this locale configuration:
  provider:    icu
  ICU locale:  en-US
  LC_COLLATE:  C
  LC_CTYPE:    C
  ...

That needs to be fixed: --no-locale should prevent any consideration
of initdb's LANG/LC_foo environment.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Order changes in PG16 since ICU introduction
Next
From: "Regina Obe"
Date:
Subject: RE: Order changes in PG16 since ICU introduction