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

  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