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.
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 |