Re: Collation versioning

It's been a bunch of years since I worked with ICU, so anything I say below
may have changed in their code or be subject to mental bit rot.

On Sun, Sep 23, 2018 at 2:48 PM Thomas Munro <thomas.munro@enterprisedb.com>
wrote:

> Considering that to handle this we'd need to figure out
> how link libicu.so.55, libicu.so.56, ... etc into the same backend,
> and yet they presumably have the same collation names,


There's an option when compiling ICU to version extend the API names. So,
instead of calling ucol_open(), you'd call ucol_open_55() or ucol_open_56()
then you can link to both libixu.so.55 and libicu.so.56 without getting
name collisions.

The side effect of this is that it's the application's responsibility to
figure out which version of ICU "en_US" should be routed to. In DB2, we
started the collation names with UCAxxx (later changed to CLDRxxx) to let
us distinguish which version of the API to call.

Admittedly that creates a whole can
> of worms for initdb-time catalog creation, package maintainers' jobs,
> how long old versions have to be supported and how you upgraded
> database objects to new ICU versions.


Yep. We never come up with a good answer for that before I left IBM. At the
time, DB2 only supported 2 or 3 version of ICU, so they were all shipped as
part of the install bundle.

Long term, I think the only viable approach to supporting multiple versions
of ICU is runtime loading of the libraries. Then it's up to the system
administrator to make sure the necessary versions are installed on the
system.

Yeah, it seems like ICU is *also* subject to minor changes that happen
> under your feet, much like libc.  For example maintenance release 60.2
> (you can't install that at the same time as 60.1, but you can install
> it at the same time as 59.2).  You'd be linked against libicu.so.60
> (and thence libicudata.so.60), and it gets upgraded in place when you
> run the local equivalent of apt-get upgrade.
>

This always worried me because an unexpected collation change is so painful
for a database. And I was never able to think of a way of reliably testing
compatibility either because of ICU's ability to reorder and group
characters when collating.