On 3/16/22 14:47, Tom Lane wrote: > Andrew Dunstan <and...@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
