Re: DROP COLLATION vs pg_collation question

Am Sun, Jun 16, 2024 at 06:53:31AM +0200 schrieb Laurenz Albe:

> On Fri, 2024-06-14 at 22:08 +0200, Karsten Hilbert wrote:
> > Are collations per-database or per-cluster objects ?
>
> Each database has its own "pg_collation" catalog table.
>
> So they are local to the database,

I would have thought so, thanks for confirming.

> but the collations themselves
> are defined by an external library, so the implementation is shared.

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 ?

> > 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 ?
>
> That should not happen. What error do you get when you
>
> ALTER COLLATION ... REFRESH VERSION

The error I got was to the effect of insufficient permissions
(the connected user wasn't the owner of the collation).
ALTERing as superuser updated collation version information
just fine, so PEBKAC.

For the record: Yes, collation versions CAN be updated
regardless of whether a given collation applies to the
database's encoding.

> Does the following give you the same error?
>
> ALTER DATABASE ... REFRESH COLLATION VERSION

That did not show the same error because I ran it as database
owner (?). The database owner does not own the collations,
however, which made the above fail.

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