Message-ID: <0f7922d4f411376f420ec9139febeae4cdc748a6.camel@j-davis.com>
Subject: Re: Collation version tracking for macOS
From: Jeff Davis <pgsql@j-davis.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Jeremy Schneider
	 <schneider@ardentperf.com>, Peter Geoghegan <pg@bowt.ie>, "Nasby, Jim"
	 <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers
	 <pgsql-hackers@postgresql.org>
Date: Mon, 28 Nov 2022 18:54:57 -0800
In-Reply-To: 
 <CA+hUKGLr=9d+-k8PVv8e__TOxuq=n0SKNDpqCzbGrK5EbDyxAg@mail.gmail.com>
References: <b37c2acd-24f4-07c9-da6e-6fec66137f69@enterprisedb.com>
	 <D9EBBA4F-C92C-4B26-AB4D-6038BC52793D@ardentperf.com>
	 <398aabd1-ad95-ba2d-d70a-dd5d90bf6e07@enterprisedb.com>
	 <CA+hUKGL36vXMfcaDq+U1ZkoSsdfFnNx7GxhGM7aYzEbKs1W0=Q@mail.gmail.com>
	 <CA+hUKGKq=iLH3bY+nK7v8b2zBCuKOk-fe0cP0it2RxNaWFVxYA@mail.gmail.com>
	 <606bd2baa6d65b38fee6eb23bba40c5da210255b.camel@j-davis.com>
	 <CA+hUKG+OSQtrRAk-bHwMJmuvqp-b-LGuxsF2PoDBVyQcT+VEAQ@mail.gmail.com>
	 <9f8e9b5a3352478d4cf7d6c0a5dd7e82496be4b6.camel@j-davis.com>
	 <CA+hUKGJxg6AbKC9RJ7r1ByVLtvVkThQV+RZO6BKVWYESPCp3Ug@mail.gmail.com>
	 <346f836208a39009c1998ed5a41c7f1a0be36911.camel@j-davis.com>
	 <CA+hUKGJhPeW3iRqO3XQB=+BTMx7O6zTCFKTfeSV9TXBtdyMqbQ@mail.gmail.com>
	 <CA+hUKGLr=9d+-k8PVv8e__TOxuq=n0SKNDpqCzbGrK5EbDyxAg@mail.gmail.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/0f7922d4f411376f420ec9139febeae4cdc748a6.camel%40j-davis.com>
Precedence: bulk

On Sat, 2022-11-26 at 18:27 +1300, Thomas Munro wrote:
> Here's the first iteration.

I will send a full review shortly, but I encountered an ICU bug along
the way, which caused me some confusion for a bit. I'll skip past the
various levels of confusion I had (burned a couple hours), and get
right to the repro:

Install the latest release of all major versions 50-69, and compile
postgres against 70. You'll get:

=3D# select * from pg_icu_collation_versions('en_US') order by
icu_version;
 icu_version | uca_version | collator_version=20
-------------+-------------+------------------
 50.2        | 6.2         | 58.0.6.50
 51.3        | 6.2         | 58.0.6.50
 52.2        | 6.2         | 58.0.6.50
 53.2        | 6.3         | 137.51
 54.2        | 7.0         | 137.56
 55.2        | 7.0         | 153.56
 56.2        | 8.0         | 153.64
 57.2        | 8.0         | 153.64
 58.3        | 9.0         | 153.72
 59.2        | 9.0         | 153.72
 60.3        | 10.0        | 153.80
 61.2        | 10.0        | 153.80
 62.2        | 11.0        | 153.88
 63.2        | 11.0        | 153.88
 64.2        | 12.1        | 153.97
 65.1        | 12.1        | 153.97
 66.1        | 13.0        | 153.14
 67.1        | 13.0        | 153.14
 68.2        | 13.0        | 153.14
 69.1        | 13.0        | 153.14
 70.1        | 14.0        | 153.112
(21 rows)

This is good information, because it tells us that major library
versions change more often than collation versions, empirically-
speaking.

But did you notice that the version went backwards from 65.1 -> 66.1?
Well, actually, it didn't. The version of that collation in 66.1 went
from 153.97 -> 153.104. But there's a bug in versionToString() that
does the decimal output incorrectly when there's a '0' digit between
the hundreds and the ones place. I'll see about reporting that, but I
thought I'd mention it here because it could have consequences, as we
are storing the strings :-(

The bug is still present in 70.1, but it's masked because it went to
.112.

Incidentally, this answers our other question about whether the
collation version can change in a minor version update. Perhaps not,
but if they fix this bug and backport it, then the version *string*
will change in a minor update. Ugh.

Regards,
	Jeff Davis