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: <6e514873-0185-d3b0-e3b2-4546be5e76f8@dunslane.net>
Date: Thu, 24 Mar 2022 12:50:42 -0700
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 Joshua Brindle <joshua.brindle@crunchydata.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Jeff Davis <pgsql@j-davis.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Joe Conway <joe@crunchydata.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1785FFEA-77C0-4939-AB52-1A91C49B65AD@enterprisedb.com>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com>
 <A9802425-8920-4814-9BE1-5C7250E2C386@enterprisedb.com>
 <E6D03A76-4D79-43BE-B896-4571E9FE323B@enterprisedb.com>
 <CAGB+Vh4_UJsYHCWborm-y4CFt8gVvY_KbcNrpWcpXAk-GcwOtA@mail.gmail.com>
 <2D6C1081-DB7D-4260-8987-5B4912E95917@enterprisedb.com>
 <1A6DA47B-2D5F-427E-AD72-1D8BD23BF94C@enterprisedb.com>
 <C8DF19D8-C15D-4C2D-91CA-391390F1E421@enterprisedb.com>
 <79685.1646604824@sss.pgh.pa.us>
 <A22EA9EA-94AC-409F-BEB8-BEF72096D97E@enterprisedb.com>
 <83814.1646607430@sss.pgh.pa.us>
 <78889A65-CA7A-4015-866D-33460967071D@enterprisedb.com>
 <92485.1646609263@sss.pgh.pa.us>
 <ADC4EBF7-87B2-438F-8BA1-8EF57F0E61CF@enterprisedb.com> <43857434-3f9b-3!
 66f-0401-7aea558827e1@dunslane.net> <664799.1647456444@sss.pgh.pa.us>
 <c87b70d9-6097-cf27-ba8b-bfb041b2e264@enterprisedb.co! m>
 <771410.1647528423@sss.pgh.pa.us>
 <9b37fa41-a068-8166-78c3-4503a867de07@dunslane.net>
 <A3799365-1920-4779-BD8A-0DC00B563416@enterprisedb.com>
 <6e514873-0185-d3b0-e3b2-4546be5e76f8@dunslane.net>
To: Andrew Dunstan <andrew@dunslane.net>
Archived-At: 
 <https://www.postgresql.org/message-id/1785FFEA-77C0-4939-AB52-1A91C49B65AD%40enterprisedb.com>
Precedence: bulk


> On Mar 24, 2022, at 12:06 PM, Andrew Dunstan <andrew@dunslane.net> =
wrote:
>=20
>=20
> On 3/24/22 12:49, Mark Dilger wrote:
>>=20
>>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan <andrew@dunslane.net> =
wrote:
>>>=20
>>> If we abandoned that for this form of GRANT/REVOKE I think we could
>>> probably get away with
>>>=20
>>>=20
>>>    GRANT { SET | ALTER SYSTEM } ON setting_name ...
>>>=20
>>>=20
>>> I haven't tried it, so I could be all wrong.
>> Version 12 of the patch uses SET and ALTER SYSTEM as the names of the =
privileges, and PARAMETER as the name of the thing on which the =
privilege is granted.  The catalog table which tracks these grants is =
now named pg_parameter_acl, and various other parts of the patch have =
been adjusted to use a "parameter" based, rather than a "setting" based, =
naming scheme.  One exception to this rule is the "setacl" column in =
pg_parameter_acl, which is much more compact than the "parameteracl" =
name would be, so that remains under the old name.
>=20
>=20
> I can live with it I guess, but it seems perverse to me to have
> pg_settings but pg_paramater_acl effectively referring to the same set
> of things. If we're going to do this perhaps we should create a
> pg_parameters view which is identical to pg_settings and deprecate
> pg_settings. I don;t want to hold up this patch, I think this can
> probably be managed as a follow up item.

Right, the version 12 patch was following Peter's and Tom's comments =
upthread:

> On Mar 17, 2022, at 7:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Well, I still say that "SET" is sufficient for the one privilege name
> (unless we really can't make Bison handle that, which I doubt).  But
> I'm willing to yield on using "ALTER SYSTEM" for the other.
>=20
> If we go with s/SETTING/PARAMETER/ as per your other message, then
> that would be adequately consistent with the docs I think.  So it'd
> be
>=20
> GRANT { SET | ALTER SYSTEM } ON PARAMETER foo TO ...
>=20
> and the new catalog would be pg_parameter_acl, and so on.

We could debate that again, but it seems awfully late in the development =
cycle.  I'd rather just get this committed, barring any objections?

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