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: <2347082.1637100769@sss.pgh.pa.us>
Date: Tue, 16 Nov 2021 14:25:12 -0800
Cc: Andrew Dunstan <andrew@dunslane.net>,
 Robert Haas <robertmhaas@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F2C67AB-D357-4353-8172-E82E54A52107@enterprisedb.com>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com>
 <CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
 <2226110.1637075835@sss.pgh.pa.us>
 <CA+TgmoYWqjpHEogdCEbRwzUb5ZoEaUt8ciNUXFCwLZDWBe+_BA@mail.gmail.com>
 <2226903.1637076537@sss.pgh.pa.us>
 <A6157072-B564-4171-8599-068C8D65BE9C@enterprisedb.com>
 <2231899.1637081047@sss.pgh.pa.us>
 <38BEC583-DB34-4918-BCBC-DC896F0D3844@enterprisedb.com>
 <055d86ff-9c95-f1d4-c974-29896767561e@dunslane.net>
 <7DFFECF0-373B-40B0-BCA0-A5ADD9266FFA@enterprisedb.com>
 <2347082.1637100769@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/9F2C67AB-D357-4353-8172-E82E54A52107%40enterprisedb.com>
Precedence: bulk


> On Nov 16, 2021, at 2:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> The question is why you need pg_config_param at all, then.
> AFAICS it just adds maintenance complexity we could do without.
> I think we'd be better off with a catalog modeled on the design of
> pg_db_role_setting, which would have entries for roles and lists
> of GUC names that those roles could set.

Originally, I was trying to have dependency linkage between two proper =
types of objects, so that DROP ROLE and DROP CONFIGURATION PARAMETER =
would behave as expected, complaining about privileges remaining rather =
than dropping an object and leaving a dangling reference.

I've deleted the whole CREATE CONFIGURATION PARAMETER and DROP =
CONFIGURATION PARAMETER syntax and implementation, but it still seems =
odd to me that:

  CREATE ROLE somebody;
  GRANT SELECT ON TABLE sometable TO ROLE somebody;
  GRANT ALTER SYSTEM ON someguc TO ROLE somebody;
  DROP ROLE somebody;
  ERROR:  role "somebody" cannot be dropped because some objects depend =
on it
  DETAIL:  privileges for table sometable

would not mention privileges for "someguc" as well.  That's why I want =
configuration parameters to be proper objects with OIDs and with entries =
in pg_depend and/or pg_shdepend.  Maybe there is some better way to do =
it, but that's why I've been doing this.

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