Hi, A while back I asked if anyone knew the rationale for requiring RESTRICT on the revoke statement when an execute privilege is revoked, but I got no reply so I am trying again :)
Similaryly, who do we not allow RESTRICT for table/column privilege? Knowing the answer might help inform a decision I have to make when specifying REVOKE <role> as part of the roles work. Short background: * Derby requires the RESTRICT semantics when revoking execution privileges. Derby does not allow RESTRICT semantics when revoking table/column privileges. That is, the revoke semantics for the two kinds of privileges are incompatible. * All kinds of privileges can be granted to a role, say role A. A user who is granted the use of role A, can then make use of privileges granted to A, both execution and table privileges, possibly relying on the for creating persistent objects (constraints, trigger or views). * If role A is now revoked from the user, should we use RESTRICT or CASCADE semantics? Since the role may enjoy both kinds of privileges at the same time, no matter which semantics we choose it would potentially be surprising given that Derby has imcompatible revoke semantics as described. If we let REVOKE <role>role have RESTRICT semantics, we would get RESTRICT semantics for table/column privileges, if such a privilege had been granted to A. Conversely, if we let REVOKE <role> have CASCADE semantics, it could surprise users if an execute privilege were had been granted to A. If I have to choose, I would say that RESTRICT seems less risky in that any surprise is less potentially damaging. What do you think? Dag
