Re: pgsql: Add option to use ICU as global locale provider
От | Julien Rouhaud |
---|---|
Тема | Re: pgsql: Add option to use ICU as global locale provider |
Дата | |
Msg-id | 20220318074051.n46mkwp2zkbxeesf@jrouhaud обсуждение исходный текст |
Ответ на | Re: pgsql: Add option to use ICU as global locale provider (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-committers |
On Fri, Mar 18, 2022 at 02:36:48PM +0800, Julien Rouhaud wrote: > On Fri, Mar 18, 2022 at 06:15:47PM +1300, Thomas Munro wrote: > > > > No idea what's happening here but one observation is that that animal > > is running an older distro that shipped with ICU 5.0. Commit b8f9a2a6 > > may hold a clue... > > Right. I'm setting up a similar podman environment, hopefully more info soon. And indeed b8f9a2a6 is the problem. We would need some form of icu_set_collation_attributes() on the frontend side if we want to detect such a problem on older ICU version at the expected moment rather than when bootstrapping the info. A similar check is also needed in createdb(). I was thinking that this could be the cause of problem reported by Andres on centos 7 (which seems to ship ICU 50), but postinit.c calls make_icu_collator(), which sets the attribute as expected. Maybe it's because old ICU version simply don't understand locale ID like "en-u-kf-upper" and silently falls back to the root collator?
В списке pgsql-committers по дате отправления: