Mamta Satoor <[EMAIL PROTECTED]> writes: > 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.
Thanks for precious time from your collation work to answer my question :) (If anyone else knows the answer to these questions it would probably be good if they could help Mamta out :) OK, I think I have confused things a bit. Forget the view (don't think it is relevant), and assume that P references T directly. Assume that some other user X created T and has granted me select privilege on T. I prepare P without problems and execute it. Then user X revokes my select privilege on T. I then try to execute P again. My understanding (based on Dan's comments earlier in this thread and in DERBY-827) is that P then should already have been marked as invalid by the revoke and that my attempt to execute P should trigger a re-compile, which in turn should fail because I no longer have select privilege on T. (This isn't what happens today btw. Currently P will not be invalid, but it checks that it has the necessary permissions on every execute, so the second execute of P will still fail) -- dt
