On Sat, Jun 11, 2022 at 3:36 PM Peter Geoghegan <p...@bowt.ie> wrote: > Do we even need to store a version for indexes most of the time if > we're versioning ICU itself, as part of the "time travelling > collations" design? For that matter, do we even need to version > collations directly anymore?
They're still useful for non-ICU collations (for example FreeBSD and Windows can tell you about version changes based on open standards), and they're *maybe* still useful for ICU, considering that there are minor version upgrades, though I hope that would never actually detect a change if we built a multi-version system like what we are discussing here. Certainly they don't make sense in the current catalog layout with TT collations, though, there's only one attribute to cover N libraries (though the reverted version tracking thing would handle it just fine, because that moved it into a per-index location). I mention minor upgrade as a topic to poke at because the popular Linux distros only allow major ICU versions to be installed concurrently, but minor versions are also released from time to time and replace the libraries (well, the .68 library is a symlink to .68.1, and then changes to .68.2, following typical conventions, but the packages don't let you have .68.1 and .68.2 at the same time). To pick a random example, ICU upgraded 68.1 -> 68.2 at one point, which a bit of googling tells me included CLDR 38 -> CLDR 38.1. It looks like they tweaked a few super minor things. Could such a change affect the values that ucol_getVersion() reports? This came up in the last round of this stuff with Doole[1], but we didn't dig further and I still don't know what to think about it. [1] https://www.postgresql.org/message-id/CADE5jYJTnYaTNXMFKOK-0p44%2BDm5LMcRcJ5kVi1MVHomb2QTkQ%40mail.gmail.com