Satheesh had added some code as part of "(DERBY-1543) Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when objects they cover are dropped." to cleanup 3 permissions related system tables when a table/routine is dropped. Maybe something similar is required when a column is dropped from a table.
Thanks, Mamta! Yes, this is a very interesting and relevant change for the issue I'm struggling with. It seems like DERBY-1543 could have been implemented using the dependency manager, but was not.
I will investigate extending the techniques used by DERBY-1543 to cover dropping a column, as you suggest. In the meantime, I'm still rather puzzled regarding the more generic question of when the various data dictionary objects use the SYSDEPENDS table and the Dependency Manager routines, and when they do not. If anybody has insight into the history or architecture here, that would be greatly appreciated. For example, why is dropping a dependent VIEW driven out of ViewDescriptor.makeInvalid, but dropping a dependent TRIGGER is driven by direct calls in the DropTableConstantAction code? There's a definite difference in the overall technique, and I'm not grasping the idea about when to use the one and when to use the other. thanks, bryan
