Re: DROP COLLATION vs pg_collation question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: DROP COLLATION vs pg_collation question
Date: 2024-06-16 20:38:49
Message-ID: 3031360.1718570329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Sun, 2024-06-16 at 11:27 +0200, Karsten Hilbert wrote:
>> Which in turn means I cannot at all truly _remove_ collations
>> from a cluster at the SQL level, only make them invisible
>> (and thereby not-to-be-used) inside a particular database by
>> removing them from pg_collations via DROP COLLATION, right ?

> As far as PostgreSQL is concerned, you can remove them.

It's really kind of moot, since you can't change the encoding
of an existing database. So any pg_collation entries that are
for an incompatible encoding cannot be used for anything in that
database, and they might as well not be there. The reason they
are there is merely an implementation detail: CREATE DATABASE clones
those catalogs from the single copy of pg_collation in template0,
which therefore had better include all collations that might be
needed.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Benoit, Eric 2024-06-17 13:46:06 WAL settings for larger imports
Previous Message Laurenz Albe 2024-06-16 17:37:08 Re: DROP COLLATION vs pg_collation question