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
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 |