From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Mark Dilger <mark.dilger@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>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
In-reply-to: <0e512c3b-31c2-7ff5-b80e-760d8ff8060e@dunslane.net>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com> <9DB8DABC-0E1E-4AB0-BB11-9BC48E4C71BE@enterprisedb.com> <df224438-bcb5-5543-8ff6-841ce91053fb@dunslane.net> <BA6C2DC4-A169-4239-B7E2-B4F73EA908E3@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> <0e512c3b-31c2-7ff5-b80e-760d8ff8060e@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Wed, 16 Mar 2022 16:07:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <675776.1647463982.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 16 Mar 2022 16:53:02 -0400
Message-ID: <675777.1647463982@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/675777.1647463982%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 3/16/22 14:47, Tom Lane wrote:
>> I'm also fairly allergic to the way that this patch has decided to assign
>> multi-word names to privilege types (ie SET VALUE, ALTER SYSTEM).  There
>> is no existing precedent for that, and I think it's going to break
>> client-side code that we don't need to break.  It's not coincidental that
>> this forces weird changes in rules about whitespace in the has_privilege
>> functions, for example; and if you think that isn't going to cause
>> problems I think you are wrong.  Perhaps we could just use "SET" and
>> "ALTER", or "SET" and "SYSTEM"?

> That's going to look weird, ISTM. This is less clear about what it's
> granting.
>      GRANT ALTER ON SOMETHING shared_buffers TO myuser;

True.  I think "GRANT SET" is clear enough, and it fits with the custom of
using the name of the SQL statement that the privilege allows you to
invoke.  (I gather from Mark's comments that Bison gave him problems with
that, but maybe that can be dealt with.)  But I concede that "ALTER" by
itself is pretty vague.

> If you don't like that maybe ALTER_SYSTEM and SET_VALUE would work,
> although mostly we have avoided things like that.
> How about MODIFY instead of SET VALUE and CONFIGURE instead of ALTER SYSTEM?

I thought about ALTER_SYSTEM too.  It's not great but maybe the best we
can do.  Not sure that CONFIGURE is better.

> Personally I don't have problem with the use of SETTING. I think the
> meaning is pretty plain in context and unlikely to produce any confusion.

I'm just unhappy about the disconnect with the documentation.  I wonder
if we could get away with s/configuration parameter/setting/g in the docs.

			regards, tom lane