On Wed, Nov 30, 2022 at 9:59 AM Jeff Davis <pgsql@j-davis.com> wrote:
> Here's what I found for the 'ar' locale (firstminor/lastminor are the
> icu library versions, firstcollversion/lastcollversion are their
> respective collation versions for the given locale):
>
> firstminor | lastminor | firstcollversion | lastcollversion
> ------------+-----------+------------------+-----------------
> 60.1 | 60.3 | 153.80.32 | 153.80.32.1
> 64.1 | 64.2 | 153.96.35 | 153.97.35.8
> 68.1 | 68.2 | 153.14.38 | 153.14.38.8
> (3 rows)
Right, this fits with what I said earlier: the third component is CLDR
major, fourth component is CLDR minor except from ICU 61 on the CLDR
minor is << 3'd (X.X.38.8 means CLDR 38.1). I wrote something about
that particular CLDR upgrade that happened in ICU 68 back here, with a
link to the CLDR change list:
https://www.postgresql.org/message-id/CA+hUKGJxg6AbKC9RJ7r1ByVLtvVkThQV+RZO6BKVWYESPCp3Ug@mail.gmail.com
TL;DR that particular CLDR change didn't actually affect collations,
it affected other locale stuff we don't care about (timezones etc).
We probably have to assume that any CLDR change *might* affect us,
though, unless we can find a written policy somewhere that says CLDR
minor changes never change sort order. But I wouldn't want to get
into 2nd guessing their ucol_getVersion() format, and if they knew
that minor changes didn't affect sort order they presumably wouldn't
have included it in the recipe, so I think we simply have to treat it
as opaque and assume that ucol_getVersion() change means what it says
on the tin: sort order might have changed.
> I suppose the next step is to test with actual data and find
> differences?
Easier to read the published CLDR deltas, but I'm not sure it'd tell
us much about what *could* happen in future releases...
