Christophe Pettus <xof@xxxxxxxxxxxx> writes: > Right now, if you do a REVOKE that doesn't actually revoke anything, it works silently. This can be a bit of a foot-gun. For example: > CREATE FUNCTION f() RETURNS int as $$ SELECT 1; $$ LANGUAGE sql; > REVOKE EXECUTE ON FUNCTION f() FROM lowpriv; > Naively, it might be expected that `lowpriv` can't execute the function, but unless default privileges have been changed, `lowpriv` still can under the default grant of EXECUTE to PUBLIC. Since there was no previous grant to `lowpriv`, nothing actually changes in the ACL. This bit a client recently. > Is it worth generating a warning in this case? To be clear, even if there had been a grant of EXECUTE to lowpriv, that role would still be able to call the function thanks to the public EXECUTE permission. I'm not sure that warning about whether anything got revoked is going to help people who fundamentally misunderstand where the privilege is coming from. Still, I take your point that maybe the command should mention that nothing happened. To me the best argument for producing a warning is that we already do so for grants of roles: regression=# create user alice; CREATE ROLE regression=# create role bob; CREATE ROLE regression=# revoke bob from alice; WARNING: role "alice" has not been granted membership in role "bob" by role "postgres" REVOKE ROLE However, ordinary privileges are a bit more complicated since multiple privilege bits can be specified: regression=# revoke select,update on table t from alice; REVOKE or even regression=# revoke select(x),update(y) on table t from alice; REVOKE Should we generate a warning when only some of the named privileges exist to be revoked? My initial reaction is that we should warn only when the command is a complete no-op, that is none of the mentioned privileges matched. But I've not thought about it very hard. regards, tom lane
