Mamta Satoor <[EMAIL PROTECTED]> writes: > Dyre, my memory has gone rusty on this topic but what I seem to recollect is > not everything dependent on table will also be dependent for TablePermsDescr > too. This is because say the table owner creates a view on that table, then > no TablePermsDescr is required by such a view but that view will depend on > the TableDescriptor.
Not sure I understand this. Assume I have a table T and a view V that references it, and that I currently have select privilege on T. Assume that I have created a prepared statement P that selects from V. If someone revokes my select privilege on T, I should no longer be allowed execute P should, I? P should become invalid as a consequence of the revoke, right? When I run the test in question (lang/grantRevokeDDL2.sql) I observe that the revoke results in DependencyManager.invalidateFor() being called on TablePermsDescr (as Provider), and that the TablePermsDescr's dependency list is empty. The TableDescr, on the other hand, appears to list the statements referring to that table as its dependents. So if there had been a dependency chain like so: TablePermsDescr -> TableDescr -> Statement a revoke would have triggered a statement re-compile. But TableDescr doesn't implement the Dependent interface, only the Provider interface (it doesn't implement makeInvalid()), and the TableDescr isn't really invalidated by the revoke, only the statement is. So perhaps the TablePermsDescr should have a direct dependency to the statement? If so; when should that dependency be established? The dependency between TableDescr and Statement happens during compilation, but the TablePermsDescr is created during execution. Can we just copy the dependents from TableDerscr to TablePermsDescr? Say, in TablePermsDescr's constructor? -- dt
