Dyre, before I can understand the entire email, I need understanding this part of your mail
"Assume I have a table T and a view V that references it, and that I currently have select privilege on T." Who owns the table T when you say I have a table T? Also, let me take the case where you are not the owner of table T and you have been granted select privilege on T, then you don't automatically get select privilege on view V. In that case, this statement doesn't sound right "I currently have select privilege on T. Assume that I have created a prepared statement P that selects from V." If you have select privileges on T only, then you should not be able to preapre a statement which selects from V. So, it will be good to know the exact ownership of the objects and the exact privileges granted to the user who is trying to prepare a statement.
On 4/23/07, Dyre.Tjeldvoll@sun.com <Dyre.Tjeldvoll@sun.com> wrote:
Mamta Satoor <email@example.com> 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?