Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
Date: Tue, 16 Nov 2021 07:24:51 -0800
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Andrew Dunstan <andrew@dunslane.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C86AB2D-87F0-43C0-A03C-02A28FFD3D9C@enterprisedb.com>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com>
 <CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/0C86AB2D-87F0-43C0-A03C-02A28FFD3D9C%40enterprisedb.com>
Precedence: bulk


> On Nov 16, 2021, at 7:03 AM, Robert Haas <robertmhaas@gmail.com> =
wrote:
>=20
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges.

The burden isn't on the installer of an extension.  As implemented, it's =
the extension's installation .sql file that sets it up, and the upgrade =
.sql files that make adjustments, if necessary.

> And
> if somebody then loads up a different .so for that extension, the set
> of GUCs that it provides can change without any DDL being executed.
> New GUCs could appear, and old GUCs could vanish.

Well, the same is true for functions, right?  If you add, remove, or =
redefine functions in the extension, you need an upgrade script that =
defines the new functions, removes the old ones, changes function =
signatures, or whatever.  The same is true here for GUCs.

I don't think we support using a .so that is mismatched against the =
version of the extension that is installed.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company