Re: Collation version tracking for macOS

On Tue, Nov 29, 2022 at 1:59 PM Jeff Davis <pgsql(at)j-davis(dot)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 continue to be confused about why collation maintainers think that
it's OK to whack stuff around in minor versions. The thought that
people might use collations to sort data that needs to stay sorted
after upgrading the library seems to be an alien one, and it doesn't
really seem like libicu is a whole lot better than libc, either.

--
Robert Haas
EDB: http://www.enterprisedb.com