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:
=# select * from pg_icu_collation_versions('en_US') order by
icu_version;
icu_version | uca_version | collator_version
-------------+-------------+------------------
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
