Re: Granting SET and ALTER SYSTE privileges for GUCs
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Andrew Dunstan <andrew@dunslane.net>
Date: 2021-11-16T16:07:36Z
Lists: pgsql-hackers
On Tue, Nov 16, 2021 at 10:45 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > You are talking about mismatches in the other direction, aren't you? I was responding to Robert's point that new gucs could appear, and old gucs disappear. That seems analogous to new functions appearing and old functions disappearing. If you upgrade (not downgrade) the .so, the new gucs and functions will be in the .so, but won't be callable/grantable from sql until the upgrade script runs. The old gucs and functions will be missing from the .so, and attempts to call them/grant them from sql before the upgrade will fail. What am I missing here? It's true that we could impose such a restriction, but I don't think we should. If I install a different .so, I want the new GUCs to be grantable immediately, without running any separate DDL. I also don't think we should burden extension authors with putting stuff in their upgrade scripts for this. We should solve the problem in our code rather than forcing them to do so in theirs. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 landed