On Mon, 31 Jul 2017 19:42:30 -0400
Peter Eisentraut <peter.eisentraut@2ndquadrant.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*@collation=tradtiional, si*@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.
--
