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?
This hardly fits in normal-size terminals:
=# \l
List of databases
Name │ Owner │ Encoding │ Collate │ Ctype │ ICU Locale │ Locale Provider │ Access privileges
───────────┼───────┼──────────┼────────────┼────────────┼────────────┼─────────────────┼───────────────────
postgres │ myon │ UTF8 │ de_DE.utf8 │ de_DE.utf8 │ │ libc │
template0 │ myon │ UTF8 │ de_DE.utf8 │ de_DE.utf8 │ │ libc │ =c/myon ↵
│ │ │ │ │ │ │ myon=CTc/myon
template1 │ myon │ UTF8 │ de_DE.utf8 │ de_DE.utf8 │ │ libc │ =c/myon ↵
│ │ │ │ │ │ │ myon=CTc/myon
(3 rows)
(Even longer if the username is "postgres")
It also makes \l+ even harder to read when the most often only
relevant new column, the database size, is even more to the far right.
Couldn't that be a single "Locale" column, possibly extended by more
info in parentheses if the values differ?
Locale
de_DE.utf8
de-x-icu-whatever
de_DE.utf8 (Ctype: C.UTF-8)
SQL_ASCII (ICU Locale: en-x-something)
Christoph
