On Tue, 2022-11-29 at 14:34 -0500, Joe Conway wrote: > I understand that it is not easily done, but if the combination of > collprovider + collversion does not represent specific immutable > ordering behavior for a given locale
Given the u_versionToString() bug, we know the version string could end up being the same between two different collation versions (e.g. 153.104 and 153.14). So that really undermines the credibility of ICU's collation versions (at least the strings, which is what we store in collversion). But if we ignore that bug, do we have evidence that the actual versions could be the same for collations that sort differently? It's worth exploring, to be sure, but right now I don't know of a case. > , what value is there in tracking [collation version]? Similarly, what is the value in tracking the library minor versions, if when you open libicui18n.63.1, you may end up with a mix of code between 63.1 and 63.2? That doesn't mean it's impossible. We could attach collations to a library major version, and tell administrators that once they install a major version in icu_library_path, they never touch that major version again (no updates or new minors, only new majors). #6 might be a good approach to facilitate this best practice. We'd then probably need to change collversion to be a library major version, and then come up with a migration path from 15 -> 16. Or we could store both library major version and collversion, and verify both. -- Jeff Davis PostgreSQL Contributor Team - AWS
