Re: Windows default locale vs initdb

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Ertan Küçükoglu <ertan(dot)kucukoglu(at)gmail(dot)com>
Subject: Re: Windows default locale vs initdb
Date: 2024-07-22 23:19:57
Message-ID: CA+hUKGKTYM3tYNr=zau1H73KpzDPuL_Ebs_cDgvvZE5xtjEH-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 23, 2024 at 1:44 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I have an environment I can use for testing. But what exactly am I
> testing? :-) Install a few "problem" language/region settings, switch
> the system and ensure initdb runs ok?

I just want to know about any weird unexpected consequences of using
BCP47 locale names, before we change the default in v18. The only
concrete thing I found so far was that MinGW didn't like it, but I
provided a fix for that. It'd still be possible to initialise a new
cluster with the old style names if you really want to, but you'd have
to pass it in explicitly; I was wondering if that could be necessary
in some pg_upgrade scenario but I guess not, it just clobbers
template0's pg_database row with values from the source database, and
recreates everything else so I think it should be fine (?). I am a
little uneasy about the new names not having .encoding but there
doesn't seem to be an issue with that (such locales exist on Unix
too), and the OS still knows which encoding they use in that case.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-07-22 23:23:45 Re: Pgoutput not capturing the generated columns
Previous Message Michael Paquier 2024-07-22 23:03:37 Re: pg_upgrade and logical replication