Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sIweQ-001V49-Ht for pgsql-general@arkaria.postgresql.org; Sun, 16 Jun 2024 20:38:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sIweO-009Tur-CG for pgsql-general@arkaria.postgresql.org; Sun, 16 Jun 2024 20:38:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sIweO-009Tui-16 for pgsql-general@lists.postgresql.org; Sun, 16 Jun 2024 20:38:56 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sIweM-001dmJ-9r for pgsql-general@lists.postgresql.org; Sun, 16 Jun 2024 20:38:55 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 45GKcno33031361; Sun, 16 Jun 2024 16:38:50 -0400 From: Tom Lane To: Laurenz Albe cc: Karsten Hilbert , pgsql-general@lists.postgresql.org Subject: Re: DROP COLLATION vs pg_collation question In-reply-to: <740fb9086af71f864ddb526cad1e55888385bedd.camel@cybertec.at> References: <26f717988471c4d672cce8c495a2c8e68446486a.camel@cybertec.at> <56da532b44bc02a7648796041ffa5da0a85c06df.camel@cybertec.at> <740fb9086af71f864ddb526cad1e55888385bedd.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Sun, 16 Jun 2024 19:37:08 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3031359.1718570329.1@sss.pgh.pa.us> Date: Sun, 16 Jun 2024 16:38:49 -0400 Message-ID: <3031360.1718570329@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laurenz Albe 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