Karsten Hilbert wrote:
> The database encoding is UTF8. That br_FR@euro.LATIN9 had
> _not_ been added manually. It is also not actively used in my
> database(s).
br_FR@euro.LATIN9 cannot be used actively in an UTF-8 database
because it's for a different encoding than the database.
It was
Is this to be expected ?
PG 15.1 on Debian:
gnumed_v22=# select *, pg_collation_actual_version(oid),
pg_encoding_to_char(collencoding) from pg_collation where collname = 'zh_TW';
-[ RECORD 1 ]---+
oid | 12985
collnam
Am Sun, Dec 04, 2022 at 10:09:47AM -0800 schrieb Adrian Klaver:
> >>following an ICU upgrade, collations in a stock Debian PG 15.1
> >>cluster now have divergent version information in pg_collations.
> >
> >Correction: this is following a libc upgrade 2.35 -> 2.36
>
> So to be clear this database
On 12/4/22 04:35, Karsten Hilbert wrote:
Am Sun, Dec 04, 2022 at 01:22:02PM +0100 schrieb Karsten Hilbert:
following an ICU upgrade, collations in a stock Debian PG 15.1
cluster now have divergent version information in pg_collations.
Correction: this is following a libc upgrade 2.35 -> 2.36
Am Sun, Dec 04, 2022 at 01:22:02PM +0100 schrieb Karsten Hilbert:
> following an ICU upgrade, collations in a stock Debian PG 15.1
> cluster now have divergent version information in pg_collations.
Correction: this is following a libc upgrade 2.35 -> 2.36
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6
Am Sun, Dec 04, 2022 at 01:22:02PM +0100 schrieb Karsten Hilbert:
> gnumed_v22=> ALTER COLLATION pg_catalog."br_FR@euro" REFRESH VERSION;
> ERROR: collation "pg_catalog.br_FR@euro" for encoding "UTF8" does not
> exist
The OS (libc) does seem to know that collation:
@hermes:
Dear all,
following an ICU upgrade, collations in a stock Debian PG 15.1
cluster now have divergent version information in pg_collations.
Now
gnumed_v22=> ALTER COLLATION pg_catalog."br_FR@euro" REFRESH VERSION;
ERROR: collation "pg_catalog.br_FR@euro" for encoding "UTF8" does n
