| From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: DROP COLLATION vs pg_collation question |
| Date: | 2024-06-18 13:02:56 |
| Message-ID: | ZnGFgH9oKiynIbY6@hermes.hilbert.loc |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Am Sun, Jun 16, 2024 at 04:38:49PM -0400 schrieb Tom Lane:
> 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.
I see, and since any database can be used as a template for
more databases, which can be create with an encoding
different from the template, it doesn't really make too much
sense to be able to remove even pg_collation entries.
So, DROP COLLATION is somewhat of a smoking gun pointed at my
foot :-)
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Johnson | 2024-06-18 13:32:43 | Re: Monitoring logical replication |
| Previous Message | Alvaro Herrera | 2024-06-18 09:46:27 | Re: How to attach partition with primary key |