Re: Move defaults toward ICU in 16?
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-02-17T18:41:40Z
Lists: pgsql-hackers
On Fri, Feb 17, 2023 at 09:01:54AM -0800, Jeff Davis wrote: > On Fri, 2023-02-17 at 00:06 -0800, Jeff Davis wrote: > > On Tue, 2023-02-14 at 09:59 -0800, Andres Freund wrote: > > > I am saying that pg_upgrade should be able to deal with the > > > difference. The > > > details of how to implement that, don't matter that much. > > > > To clarify, you're saying that pg_upgrade should simply update > > pg_database to set the new databases' collation fields equal to that > > of > > the old cluster? > > Thinking about this more, it's not clear to me if this would be in > scope for pg_upgrade or not. If pg_upgrade is fixing up the new cluster > rather than checking for compatibility, why doesn't it just take over > and do the initdb for the new cluster itself? That would be less > confusing for users, and avoid some weirdness (like, if you drop the > database "postgres" on the original, why does it reappear after an > upgrade?). > > Someone might want to do something interesting to the new cluster > before the upgrade, but it's not clear from the docs what would be both > useful and safe. This came up before - I'm of the opinion that it's unsupported and/or useless to try to do anything on the new cluster between initdb and pg_upgrade. https://www.postgresql.org/message-id/20220707184410.GB13040@telsasoft.com https://www.postgresql.org/message-id/20220905170322.GM31833@telsasoft.com -- Justin
Commits
-
Build ICU support by default.
- fcb21b3acdcb 16.0 landed
-
Use ICU by default at initdb time.
- 27b62377b47f 16.0 landed
-
pg_upgrade: copy locale and encoding information to new cluster.
- 9637badd9f92 16.0 landed