Re: pgsql: Add option to use ICU as global locale provider

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add option to use ICU as global locale provider
Date: 2022-03-20 10:04:17
Message-ID: 2298daf1-c9c7-be30-7319-519a768b9405@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Julien Rouhaud 2022-03-20 11:46:26 Re: pgsql: Add option to use ICU as global locale provider
Previous Message Peter Eisentraut 2022-03-20 10:03:38 Re: pgsql: Add option to use ICU as global locale provider

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2022-03-20 11:23:39 Re: Column Filtering in Logical Replication
Previous Message Peter Eisentraut 2022-03-20 10:03:38 Re: pgsql: Add option to use ICU as global locale provider