Thanks for giving me the background info, Dyre. I see now the problem you are trying to address. With the collation work, I haven't been able to keep up with the list and so was not aware of the background of this thread.
One thing that comes to my mind with privilege checking only at first execution is will it be a problem if different users execute the same statement? Will we be able to know that even if the statement has already been executed once, we should do the privilege checking because this time, it is a different user who is executing the statement. Mamta On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Mamta Satoor <[EMAIL PROTECTED]> writes: > Dyre, I don't remember now if we discussed the 2 possible implementation > choices ie to invalidate prepared statements by making them depend on > privileges needed vs just catch privilege revocation at prepared statement > execute time. I wonder if there is anything in the Derby dev list archive > about this. Again, thanks for taking the time to look at this. I'll scan the archives and see what I can find. > It seems like though that privilege revocation does get caught at execute > time with the current implementation. Yes, but it happens inside fillResultSet(). Currently that method gets called on every execution, but we are (DERBY-827) trying to make it happen only on the first execution. > Does that approach not work in some circumstances and is that why we > are disucssing that approach? It works just fine. I've tested modifying the call to generateAuthorizeCheck() so that it adds its code to execute(), rather than fillResultSet(), and this makes the test pass (and I haven't noticed any negative side effects). However, Dan wrote earlier in this thread (Tue, 03 Apr 2007 07:07:40 -0700): "I think that the checking authorization once is the desired behaviour, not every execution, for performance reasons. The statements should be invalidated when a revoke is executed." So that's why I'm looking at this... -- dt
