Re: The dangers of streaming across versions of glibc: A cautionary tale - Mailing list pgsql-general

From Peter Geoghegan
Subject Re: The dangers of streaming across versions of glibc: A cautionary tale
Date
Msg-id CAEYLb_WvdCzuL=Cyf1xyzjwn-1CVo6kZEaWMKbxTS3jPhtjOig@mail.gmail.com
Whole thread Raw
In response to Re: The dangers of streaming across versions of glibc: A cautionary tale  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: The dangers of streaming across versions of glibc: A cautionary tale  (Matthew Kelly <mkelly@tripadvisor.com>)
List pgsql-general
On Wed, Aug 6, 2014 at 6:30 PM, Tatsuo Ishii <ishii@postgresql.org> wrote:
> Another idea could be having our own collation data to isolate any
> changes from outside world. I vaguley recall this had been discussed
> before.

That's probably the best solution. It would not be the first time that
we decided to stop relying on the operating system's facilities due to
various problems (e.g. we used to use the C standard library qsort()
until about 2006). The only problem is that it's a lot of work. One
possible solution that has been proposed is to adopt ICU [1]. That
might allow us to say "this is the official way that PostgreSQL 9.6
sorts Japanese; you may use the old way if you want, but it's
incompatible with the new way". ICU would give us a standard
versioning interface [2]. They seem to take this seriously, and are
aware of our considerations around B-Tree indexes on text.

[1] https://wiki.postgresql.org/wiki/Todo:ICU
[2] http://userguide.icu-project.org/collation/architecture#TOC-Versioning
--
Regards,
Peter Geoghegan


pgsql-general by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: The dangers of streaming across versions of glibc: A cautionary tale
Next
From: Phoenix Kiula
Date:
Subject: Re: Reindex taking forever, and 99% CPU