Re: The dangers of streaming across versions of glibc: A cautionary tale

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: The dangers of streaming across versions of glibc: A cautionary tale
Дата
Msg-id CAEYLb_WvdCzuL=Cyf1xyzjwn-1CVo6kZEaWMKbxTS3jPhtjOig@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The dangers of streaming across versions of glibc: A cautionary tale  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: The dangers of streaming across versions of glibc: A cautionary tale  (Matthew Kelly <mkelly@tripadvisor.com>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: The dangers of streaming across versions of glibc: A cautionary tale
Следующее
От: Phoenix Kiula
Дата:
Сообщение: Re: Reindex taking forever, and 99% CPU