Re: PostgreSQL 10 (latest beta) and older ICU

From: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostgreSQL 10 (latest beta) and older ICU
Date: 2017-08-01 06:12:21
Message-ID: 20170801091221.7283ff1f@fafnir.local.vm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 31 Jul 2017 19:42:30 -0400
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 7/25/17 15:20, Victor Wagner wrote:
> > It turns out, that PostgreSQL enumerates collations for all ICU
> > locales and passes it into uloc_toLanguageTag function with strict
> > argument of this function set to TRUE. But for some locales
> > (es*(at)collation=tradtiional, si*(at)collation=dictionary) only call with
> > strict=FALSE succeeds in ICU 4.2. In newer versions of ICU all
> > locales can be resolved with strict=TRUE.
>
> We are only calling uloc_toLanguageTag() with keyword/value
> combinations that ICU itself previously told us were supported. So
> just ignoring errors doesn't seem proper in this case.
>

We know that this version of ICU is broken. But what choice we have?
Locale code in the glibc is much more broken.
So we just have to work around bugs in underlaying libraries anyway.
In case of ICU we just need to omit some collations.

It might cause incompatibility with newer systems where these
collations are used, but if we fall back to glibc locale, there would
be much more incompatibilites. And also there is bug in strxfrm, which
prevents use of abbreviated keys.

--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-08-01 06:16:23 foreign table creation and NOT VALID check constraints
Previous Message Shay Rojansky 2017-08-01 05:23:57 Re: PostgreSQL not setting OpenSSL session id context?