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-hackers@lists.postgresql.org
Date: 2022-03-18T09:27:49Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-global-icu-collations-for-ICU-54.patch (text/plain)
(moving to -hackers) On Fri, Mar 18, 2022 at 03:40:51PM +0800, Julien Rouhaud wrote: > 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'm attaching a patch that fixes both issues for me with ICU 50. Note that there's already a test that would have failed for CREATE DATABASE if initdb tests didn't fail first, so no new test needed. I ended up copy/pasting icu_set_collation_attributes() in initdb.c. There shouldn't be new attributes added in old ICU versions, and there are enough differences to make it work in the frontend that it didn't seems worth to have a single function.
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