On Tue, Nov 16, 2021 at 2:48 PM Mark Dilger
<mark.dilger@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
toGRANT commands. That also handles the issues of extension upgrades, which I think the old patch handled better than
thediscussion 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
ofbehavior (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
stronglythat 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
havedifferent 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