Re: proposal: change behavior on collation version mismatch

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: change behavior on collation version mismatch
Date: 2023-11-27 19:17:44
Message-ID: b0c5bb6f06a9b72cd52e45af1e04168380b44769.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote:
> First: I'd suggest that a collation version mismatch should cause an
> ERROR rather than a WARNING by default. If we want to have a GUC that
> allows warning behavior, I think that's OK but I think it should be
> superuser-only and documented as a "developer" setting similar to
> zero_damaged_pages.
>
> Second: I'd suggest that all of the "alter ... refresh collation"
> commands should be strictly superuser-only rather than
> owner-of-collation-privs, and that they should be similarly documented
> as something that is generally advised against and exists for
> extraordinary circumstances.

Thanks for spending thought on this painful subject.

I can get behind changing the collation version mismatch warning into
an error. It would cause more annoyance, but might avert bigger pain
later on.

But I don't think that ALTER DATABASE ... REFRESH COLLATION VERSION
need be superuser-only. Whoever creates an object may alter it in
PostgreSQL, and system collations are owned by the bootstrap superuser
anyway. The point of the warning (or proposed error) is that the user
knows "here is a potential problem, have a closer look".

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2023-11-27 19:19:45 Re: proposal: change behavior on collation version mismatch
Previous Message Nathan Bossart 2023-11-27 19:14:39 Re: Do away with a few backwards compatibility macros