Re: Collation version tracking for macOS

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