On Wed, 2022-11-30 at 08:41 +1300, Thomas Munro wrote: > In terms of user experience, I think that might mean that users of > 'zh' who encounter warnings after a minor upgrade would therefore > really only have the options of REFRESHing and rebuilding, or > downgrading the package, because there's no way for us to access the > older version. Users of 'en' probably only encounter collversion > changes when moving between OS releases with an ICU major version > change, and then the various schemes in this thread can help them > avoid the need to rebuild, until they eventually want to, if ever.
I installed the first minor release for each major, and got some new tables. I think we can all agree that it's a lot easier to work with information once it's in table form. 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) For 'en': firstminor | lastminor | firstcollversion | lastcollversion ------------+-----------+------------------+----------------- 64.1 | 64.2 | 153.96 | 153.97 (1 row) And for 'zh': 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) It looks like collation versions do change in minor releases. It looks like it's *not* safe to lock a collation to a major version *if* that major version could be updated to a new minor. And we can't lock to a minor, as I said earlier. Therefore, once we lock a collation down to a major release, we better keep that in the icu_library_path, and never touch it, and never install a new minor for that major. Then again, maybe some of these are just about how the version is reported... maybe 153.80.32 and 153.80.32.1 are really the same version? But 64.1 -> 64.2 looks like a real difference. I suppose the next step is to test with actual data and find differences? -- Jeff Davis PostgreSQL Contributor Team - AWS