Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU
От | Victor Wagner |
---|---|
Тема | Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU |
Дата | |
Msg-id | 20170801091221.7283ff1f@fafnir.local.vm обсуждение исходный текст |
Ответ на | Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU
|
Список | pgsql-hackers |
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. --
В списке pgsql-hackers по дате отправления: