Message-ID: <0e512c3b-31c2-7ff5-b80e-760d8ff8060e@dunslane.net>
Date: Wed, 16 Mar 2022 16:07:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
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>
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>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <664799.1647456444@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/0e512c3b-31c2-7ff5-b80e-760d8ff8060e%40dunslane.net>
Precedence: bulk


On 3/16/22 14:47, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Generally I think this is now in fairly good shape, I've played with it
>> and it seems to do what I expect in every case, and the things I found
>> surprising are gone.
> Stepping back a bit ... do we really want to institutionalize the
> term "setting" for GUC variables?  I realize that the view pg_settings
> exists, but the documentation generally prefers the term "configuration
> parameters".  Where config.sgml uses "setting" as a noun, it's usually
> talking about a specific concrete value for a parameter, and you can
> argue that the view's name comports with that meaning.  But you can't
> GRANT a parameter's current value.
>
> I don't have a better name to offer offhand --- I surely am not proposing
> that we change the syntax to be "GRANT ... ON CONFIGURATION PARAMETER x",
> because that's way too wordy.  But now is the time to bikeshed if we're
> gonna bikeshed, or else admit that we're not interested in precise
> vocabulary.
>
> 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;

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?

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.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com