On Tue, Nov 16, 2021 at 2:48 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > I'm preparing a new version of the patch that has the catalog empty to begin > with, and only adds values in response to GRANT commands. That also handles > the issues of extension upgrades, which I think the old patch handled better > than the discussion on this thread suggested, but no matter. The new > behavior will allow granting privileges on non-existent gucs, just as ALTER > ROLE..SET allows registering settings on non-existent gucs. > > The reason I had resisted allowing grants of privileges on non-existent gucs > is that you can get the following sort of behavior (note the last two lines): > > DROP USER regress_priv_user7; > ERROR: role "regress_priv_user7" cannot be dropped because some objects > depend on it > DETAIL: privileges for table persons2 > privileges for configuration parameter sort_mem > privileges for configuration parameter no_such_param > > Rejecting "no_such_param" in the original GRANT statement seemed cleaner to > me, but this discussion suggests pretty strongly that I can't do it that way.
I think it's perfectly fine to refuse a GRANT statement on a GUC that doesn't exist, and I don't believe I ever said otherwise. What I don't think is OK is to require a preparatory statement like CREATE CONFIGURATION PARAMETER to be executed before you can grant permissions on it. There's no reason for that. If somebody tries to grant privileges on a GUC that does not exist, fail. If the GUC does exist but there's no catalog entry, make one. If the GUC exists and the catalog entry also exists, update it. At REVOKE time, don't check whether the GUC exists - only check the catalog. That way people can remove privileges on GUCs that don't exist any more. If somebody issues a REVOKE and there's no catalog entry, do nothing. If somebody issues a REVOKE and there is a catalog entry, remove stuff from it; but if that would leave it completely empty, instead delete it. Whenever you create a catalog entry, also add dependency entries pointing to it. When you delete one, remove those entries. > Changing the historical "sort_mem" to the canonical "work_mem" name also > seems better to me, as otherwise you could have different grants on the same > GUC under different names. I'm inclined to keep the canonicalization of > names where known, but maybe that runs afoul the rule that these grants > should not be tied very hard to the GUC? No. If somebody grants privileges on an old name, record the grant under the canonical name. -- Robert Haas EDB: http://www.enterprisedb.com
