Re: pgsql: Add option to use ICU as global locale provider
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Christoph Berg <myon@debian.org>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-03-20T10:04:17Z
Lists: pgsql-hackers
On 19.03.22 18:53, Christoph Berg wrote: > Re: Peter Eisentraut >> Since some (legacy) code still uses the libc locale facilities >> directly, we still need to set the libc global locale settings even if >> ICU is otherwise selected. So pg_database now has three >> locale-related fields: the existing datcollate and datctype, which are >> always set, and a new daticulocale, which is only set if ICU is >> selected. A similar change is made in pg_collation for consistency, >> but in that case, only the libc-related fields or the ICU-related >> field is set, never both. > > Since the intended usage seems to be that databases should either be > using libc, or the ICU locales, but probably not both at the same > time, does it make sense to clutter the already very wide `psql -l` > output with two new extra columns? Good point, let me think about that.
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