From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
cc: Thomas Munro <thomas.munro@gmail.com>, Rod Taylor <rbt@rbt.ca>,
        Jim Nasby <nasbyj@amazon.com>,
        Jeremy Schneider <schneider@ardentperf.com>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Pgsql-Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Collation version tracking for macOS
In-reply-to: <6b0bc332-ed6d-4848-a128-4dd63d1160a1@manitou-mail.org>
References: <6b0bc332-ed6d-4848-a128-4dd63d1160a1@manitou-mail.org>
Comments: In-reply-to "Daniel Verite" <daniel@manitou-mail.org>
	message dated "Wed, 08 Jun 2022 21:40:43 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1738482.1654718503.1@sss.pgh.pa.us>
Date: Wed, 08 Jun 2022 16:01:43 -0400
Message-ID: <1738483.1654718503@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1738483.1654718503%40sss.pgh.pa.us>
Precedence: bulk

"Daniel Verite" <daniel@manitou-mail.org> writes:
> Independently of these rules, all Unicode collations change frequently
> because each release of Unicode adds new characters. Any string
> that contains a code point that was previously unassigned is going
> to be sorted differently by all collations when that code point gets
> assigned to a character.
> Therefore the versions of all collations need to be bumped at every
> Unicode release. This is what ICU does.

I'm very skeptical of this process as being a reason to push users
to reindex everything in sight.  If U+NNNN was not a thing last year,
there's no reason to expect that it appears in anyone's existing data,
and therefore the fact that it sorts differently this year is a poor
excuse for sounding time-to-reindex alarm bells.

I'm quite concerned that we are going to be training users to ignore
collation-change warnings.  They have got to be a lot better targeted
than this, or we're just wasting everyone's time, including ours.

			regards, tom lane