Re: DROP COLLATION vs pg_collation question

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: DROP COLLATION vs pg_collation question
Date: 2024-06-14 20:08:04
Message-ID: ZmyjJA0jGU5TL64I@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Am Thu, Jun 13, 2024 at 09:49:46AM +0200 schrieb Laurenz Albe:

> > > Note that with DROP COLLATION you can only remove collations
> > > that belong to the encoding of your current database.
>
> src/backend/catalog/namespace.c:
>
> /*
> * get_collation_oid - find a collation by possibly qualified name
> *
> * Note that this will only find collations that work with the current
> * database's encoding.
> */
> Oid
> get_collation_oid(List *collname, bool missing_ok)

Thanks.

Are collations per-database or per-cluster objects ?

I am asking because I seem to not be enabled to

1) use a collation that's intended for an encoding different
from the database encoding

-> makes sense

2) remove a collation that's intended for an encoding
different from the database encoding

-> so far so good, ignore them, but

3) update collation version information in pg_collations for
collations intended for an encoding different from the
database encoding (ALTER COLLATION ... REFRESH VERSION fails)

which in effect would mean that -- upon change of collation
versions in the underlying operating system (ICU update, libc
update) -- one would have to live with outdated version
information in pg_collations short of dump/sed/restore or
some such ?

I'm pretty sure I am overlooking something.

Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dragam 2024-06-15 12:40:31 pgstattuple - can it/does it provide stats by partition?
Previous Message Adrian Klaver 2024-06-14 14:32:04 Re: Configure autovacuum