I got a broader view of the whole picture and obviously my proposal=20=20
that the superuser automatically revokes the privileges granted by all=20=
=20
others does not make sense. So let me state the solutions I propose to=20=
=20
the problem I'm facing:
(1) In the documentation for REVOKE, after the paragraph that begins=20=20
with "A user can only revoke privileges that were granted directly by=20=20
that user." add another paragraph similar to this:
"The rule stated in the previous paragraph is also valid for the=20=20
superuser. The superuser can however issue SET ROLE commands to revoke=20=
=20
the privileges granted by the desired users."
(2) In the documentation for REVOKE, state clearly that REVOKE will=20=20
fail silently if the user issuing the command is not the grantor. Do so=20=
=20
preferably near the bit about the superuser above.
(3) When issuing the command REVOKE <PRIV> ON <OBJ> FROM <USER>, issue=20=
=20
a NOTICE or WARNING message when, after executing it, the user <USER>=20=20
has still privilege <PRIV> on object <OBJ>.
(4) Add a GRANTED BY <USER> extension to the REVOKE command which=20=20
allows to revoke permissions given by other users, where <USER> can be=20=
=20
ALL. Obviously it would be subject to other checks which could make it=20=
=20
fail.
Of course 2 and 3 are mutually exclusive. Solution 1+2 is the simplest,=20=
=20
as it only involves documentation. Solution 1+3 would be enough to=20=20
avoid most surprises. Solution 1+3+4 would be ideal.
