On Fri, Jun 10, 2022 at 9:08 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > 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.
Right. I was mostly just asking this as a rhetorical question. What about "time travel collations", but without the time travel part? That is, what about supporting multiple ICU versions per cluster, but not per database? So you could upgrade the OS and Postgres, using standard packages that typically just use the latest ICU version -- typically, but not always. If you happen to have been on an older version of ICU on upgrade, then that version of ICU will still work at the level of a whole database -- your database. Maybe you can create new databases with old and new ICU versions if you want to. That obviously runs into the problem of needing to eventually do a dump and reload -- but I suppose that "eventually" could be a very long time. At least the OS package doesn't declare one version of ICU the blessed version, now and forever, effectively vendoring ICU in a backdoor fashion. At least old databases have significant runway, while at the same time new databases that want to use the same standard Postgres package aren't forced to use the same ancient ICU version. -- Peter Geoghegan
