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
