On Wed, Nov 30, 2022 at 8:52 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 29, 2022 at 1:59 PM Jeff Davis <pgsql@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.