On Mon, 31 Jul 2017 19:42:30 -0400 Peter Eisentraut <peter.eisentr...@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. -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
