Hi, On 2023-02-17 09:01:54 -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?
Yes. > Thinking about this more, it's not clear to me if this would be in > scope for pg_upgrade or not. I don't think we should consider changing the default collation provider without making this more seamless, one way or another. > 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?). I've wondered about that as well. There are some initdb-time options you can set, but pg_upgrade could forward those. Greetings, Andres Freund
