On Wed, Nov 30, 2022 at 8:52 AM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 29, 2022 at 1:59 PM Jeff Davis <pg...@j-davis.com> wrote: > > 6. Create a new concept of a "locked down collation" that points at > > some specific collation code (identified by some combination of library > > version and collation version or whatever else can be used to identify > > it). If a collation is locked down, it would never have a fallback or > > any other magic, it would either find the code it's looking for, or > > fail. If a collation is not locked down, it would look only in the > > built-in ICU library, and warn if it detects some kind of change > > (again, by whatever heuristic we think is reasonable). > > It seems like it would be somewhat reasonable to allow varying levels > of specificity in saying which what suffix to append when calling > dlopen() on the ICU library. Like you could allow adding nothing, > which would find the system-default ICU, or you could add 53 to find > the default version of ICU 53, or you could 53.1 to pick a specific > minor version. The idea is that the symlinks in the filesystem would > be responsible for sorting out the meaning of the supplied string. The > way that minor versions work may preclude having this work as well as > one might hope, though.
I'm struggling to understand what's new about proposal #6. The earlier proposals except #1 already contemplated different levels of locked-down-ness. For example in the libversion-as-provider idea, we said you could use just provider = ICU (warn me if the collverison changes, but always use the "default" library and carry on, pretty much like today except perhaps "the default" can be changed with a GUC), or you could be more specific and say provider = ICU63. (We also mentioned ICU63_2 as a third level of specificity, but maybe that's practically impossible.) And it was the same for the other ideas, just encoded in different ways.
