Message-ID: <2a7feb71dbdcea31478b3974b8075982ac2326d2.camel@j-davis.com>
Subject: Re: Move defaults toward ICU in 16?
From: Jeff Davis <pgsql@j-davis.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, 
	Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: Fri, 17 Feb 2023 09:01:54 -0800
In-Reply-To: <e4387c6959c9ed0d6dc9f14e01ff191f3e1a30c0.camel@j-davis.com>
References: <510d284759f6e943ce15096167760b2edcb2e700.camel@j-davis.com>
	 <CA+TgmoaymD=TA=4VB=An4LpY6FLmEnzB2NKMUBcQWOCeV-dWeA@mail.gmail.com>
	 <b676252eeb57ab8da9dbb411d0ccace95caeda0a.camel@j-davis.com>
	 <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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu1 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/2a7feb71dbdcea31478b3974b8075982ac2326d2.camel%40j-davis.com>
Precedence: bulk

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

Regards,
	Jeff Davis