Re: pgsql: Add option to use ICU as global locale provider
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter@eisentraut.org>, pgsql-committers <pgsql-committers@lists.postgresql.org>
Date: 2022-03-18T07:40:51Z
Lists: pgsql-hackers
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?
Commits
-
psql: fix \l display for pre-v15 databases.
- 7129a9791eaf 15.0 landed
-
Fix global ICU collations for ICU < 54
- 3a671e1f7cb8 15.0 landed
-
Add option to use ICU as global locale provider
- f2553d43060e 15.0 cited
-
Add support for collation attributes on older ICU versions
- b8f9a2a69a27 12.0 cited