> On Mar 6, 2022, at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I don't think this is materially different from what we do with
> permissions on (say) functions. If you want to revoke the public
> SET privilege on some USERSET variable, you instantiate the default
> and then revoke. You end up with an empty ACL stored in pg_setting_acl,
> and voila.
I assume you mean the implementation of REVOKE does this, not that the user needs to do both a grant and a revoke.
> It'd likely be necessary to refuse to record a grant/revoke on
> an unknown GUC, since if we don't know the GUC then we can't know
> what the relevant default ACL ought to be. But I bet your existing
> patch has some dubious behavior in that case too.
The existing patch allows grants on unknown gucs, because it can't know what guc an upgrade script will introduce, and
thegrant statement may need to execute before the guc exists. That opens a window for granting privileges on
non-existentgucs. That sounds bad, but I don't know of any actual harm that it does, beyond just being ugly.
With your proposal, it sounds like we could avoid that ugliness, so I'm inclined to at least try doing it as you
propose.
Thanks for the suggestion!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
