After reading you mail, it seems like with revoke, I can send specific action type to dependent objects ie say REVOKE_SELECT_PRIVILEGE / REVOKE_UPDATE_PRIVILEGE / REVOKE_REFERENCES_PRIVILEGE etc rather than generic REVOKE_PRIVILEGE and that way dependent objects can see if they depend on that specific revoke privilege on the table. I think this should provide me with enough information to decide if an object is really impacted by a revoke or not.
In order to implement the question you raised, I think I can fine tune the action types even more ie rather than sending REVOKE_SELECT_PRIVILEGE for say a REVOKE SELECT on table FROM ..., I can send REVOKE_SELECT_PRIVILEGE_USER or REVOKE_SELECT_PRIVILEGE_PUBLIC and then the dependent objects can see if they can find a privilege at PUBLIC level or user level respectively and if yes, then start depending on the newly found privilege. If not, then the object should drop itself.
thanks for the pointer,
Mamta
On 7/10/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Mamta Satoor wrote:
> That is on my todo list to figure out when I do the revoke privilege
> implementation. But I am thinking that when a revoke privilege is
> processed,
> before dropping the dependent objects, a check will be made to see if some
> other privilege can replace the privilege being revoked and if so, then
> make
> the objects depend on the newly found privilege. I have not spent enough
> time yet to figure out exactly how I would code this.
I think it's very much tied up with the question you are asking.
One can use the dependency system as either:
- Specific items (permissions) have been changed/dropped and the
dependent (the view) needs to take specific action (e.g. check the
select priv for public if select priv for user has been revoked)
- Something the dependent (the view) depends on has changed and so the
view needs to re-verify itself, which could be recompiling successfully,
or being dropped.
The dependency system will just perform a callback on the dependent with
an action type, it's up to the dependent to decide what to do with that
information.
Dan.
