Date: Fri, 17 Feb 2023 12:41:40 -0600
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
Subject: Re: Move defaults toward ICU in 16?
Message-ID: <20230217184140.GY1653@telsasoft.com>
References: 
 <CA+hUKGLd3ESz2yZ69HB6TO2E9J0Ku_eBJ5AddPHQvW+iPZ-puA@mail.gmail.com>
 <1590310.1675379449@sss.pgh.pa.us>
 <337d581bae5d6253919f70acdfc184631f0ad41b.camel@j-davis.com>
 <20230209022234.gihj4apas6ycaddq@awork3.anarazel.de>
 <5ffeafe843d43a975f31479fbd211ab88404841b.camel@j-davis.com>
 <20230211020042.uthdgj72kp3xlqam@awork3.anarazel.de>
 <d47923e2774cb5e5b6207f8678ffcc11bd110c4a.camel@j-davis.com>
 <20230214175957.idkb7shsqzp5nbll@awork3.anarazel.de>
 <e4387c6959c9ed0d6dc9f14e01ff191f3e1a30c0.camel@j-davis.com>
 <2a7feb71dbdcea31478b3974b8075982ac2326d2.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2a7feb71dbdcea31478b3974b8075982ac2326d2.camel@j-davis.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20230217184140.GY1653%40telsasoft.com>
Precedence: bulk

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