Re: Q: error on updating collation version information

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Karsten Hilbert" <Karsten(dot)Hilbert(at)gmx(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Q: error on updating collation version information
Date: 2022-12-05 10:51:34
Message-ID: 9aec6e6d-318e-4a36-96a4-3b898c3600c9@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Karsten Hilbert wrote:

> The database encoding is UTF8. That br_FR(at)euro(dot)LATIN9 had
> _not_ been added manually. It is also not actively used in my
> database(s).

br_FR(at)euro(dot)LATIN9 cannot be used actively in an UTF-8 database
because it's for a different encoding than the database.

It was probably available in the OS at initdb time. Every available
locale (see locale -a) gets imported into the template databases,
and then into the other databases, since CREATE DATABASE copies a
template without filtering out the locales that are incompatible
with the target database.

There's no need to upgrade anything in the OS to get the
ALTER COLLATION... REFRESH error you mention.
It's sufficient to have a mix of collations for different encodings
and try to refresh collations whose encoding are not compatible
with the current database.

> What is the canonical advice on the way forward here ? Is
> the _suggested_ solution to delete the collation or am I
> missing to see the "proper" approach to fixing it ?

ISTM that dropping that collation from any non-LATIN9 database
is the more sensible action.


Maybe it could be discussed as a possible improvement to have
ALTER COLLATION... REFRESH ignore the database encoding and still
refresh the version number.

Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn Tonies (Upscene Productions) 2022-12-05 10:55:24 Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Previous Message Martijn Tonies (Upscene Productions) 2022-12-05 10:48:53 Re: Stored procedure code no longer stored in v14 and v15, changed behaviour