Re: Windows default locale vs initdb - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Windows default locale vs initdb
Date
Msg-id CA+hUKGJcL-hGjtiydSNbSYavyyYBYXy8HSQ6vMz=R9-qMY=A7w@mail.gmail.com
Whole thread Raw
In response to Re: Windows default locale vs initdb  (Zaid Shabbir <zaidshabbir@gmail.com>)
List pgsql-hackers
On Mon, Jul 22, 2024 at 8:38 PM Zaid Shabbir <zaidshabbir@gmail.com> wrote:
> Can you please list down some of the use cases for the patch ? Other than Turkish, does this patch have an impact on
otherlocales too ? 

Hi Zaid,

Yes, initdb.exe would use BCP47 codes by default for all languages.
Who knows which country will change its name next?

From a quick search of other recent cases: Czech Republic -> Czechia,
Swaziland -> Eswatini, Cape Verde -> Cabo Verde, and more, plus others
that we have older records of in the mailing list that seemed to
change in some minor technical way: Macau, Hong Hong, Norwegian etc.
The Windows manual says:

"We do not recommend this form for locale strings embedded in
code or serialized to storage, because these strings are more likely
to be changed by an operating system update than the locale name
form."

It's pretty bad for our users when it happens and the Windows locale
name changes: a database cluster that suddenly can't start, and even
after you've figured out why and adjusted the references in
postgresql.conf, you still can't connect.  There is also the problem
that some of the old full names have non-ASCII characters (Türkiye,
São Tomé and Príncipe, Curaçao, Côte d'Ivoire, Åland) which is bad at
least in theory because we use the string in times and places when it
it is not clear what the encoding the name itself has.

I don't use Windows myself, I've just been watching this train wreck
replaying in a loop for long enough.  Clearly it's going to take some
time to wean the user community off the unstable names, and it struck
me that the default is probably the main source of them in new
clusters, hence this patch.



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Possible incorrect row estimation for Gather paths
Next
From: Amit Kapila
Date:
Subject: Re: pg_upgrade and logical replication