Re: Collation versioning - Mailing list pgsql-hackers

On Tue, Sep 18, 2018 at 7:57 AM Douglas Doole <dougdoole@gmail.com> wrote:
> On Mon, Sep 17, 2018 at 12:32 PM Greg Stark <stark@mit.edu> wrote:
>> This seems like a terrible idea in the open source world. Surely collation versioning means new ICU libraries can
stillprovide the old collation rules so even if you update the library you can request the old version? We shouldn't
needthat actual old code with all its security holes and bugs just to get the old collation version. 
>
>
> We asked long and hard for this feature from the ICU team but they kept arguing it was too hard to do. There are
apparentlysome tight couplings between the code and each version of CLDR. So the only way to support old collations is
toship the entire old library. (They even added make rules to allow the entire API to be version extended to
accommodatethis requirement.) 

I wonder if this would be best modelled by entirely separate collation
entries with different OIDs, and possibly also separate collation
providers.  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, doing it as
separate providers would create separate namespaces for their
collcollate values and reflect the reality that they really are
entirely independent providers.  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.  This kind of "major" versioning
with support for concurrently accessible major versions seems to be
different from the kind of version changes that happen under your feet
when libraries/collation definition files are updated.

> Even bug fixes are potentially problematic because the fix may alter how some code points collate. The ICU team won't
(orat least wouldn't - been a few years since I dealt with them) guarantee any sort of backwards compatibility between
codedrops. 

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.

--
Thomas Munro
http://www.enterprisedb.com