> On Mar 6, 2022, at 2:57 PM, Tom Lane <t...@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 the grant statement may need to
execute before the guc exists. That opens a window for granting privileges on
non-existent gucs. 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
