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

  1. psql: fix \l display for pre-v15 databases.

  2. Fix global ICU collations for ICU < 54

  3. Add option to use ICU as global locale provider

  4. Add support for collation attributes on older ICU versions