I've been writing additional tests for ALTER TABLE DROP COLUMN and have come across a few questions:
1) When I specify RESTRICT, the code searches for dependent objects and rejects the DROP COLUMN if a dependent item is found. However, an index is apparently not considered a dependent item. That is: ij> create table atdc_4 (a int, b int); 0 rows inserted/updated/deleted ij> create index atdc_4_idx_1 on atdc_4 (a); 0 rows inserted/updated/deleted ij> -- This succeeds, but it seems to me that it should fail. alter table atdc_4 drop column a restrict; 0 rows inserted/updated/deleted 2) When I specify CASCADE, the code which drops the column also drops the dependent objects. However, cascade processing apparently is unable to drop a view. That is: create table atdc_5 (a int, b int); 0 rows inserted/updated/deleted ij> create view atdc_vw_1 (vw_b) as select b from atdc_5; 0 rows inserted/updated/deleted ij> -- This fails, but it seems to me that it should succeed. alter table atdc_5 drop column b cascade; ERROR X0Y23: Operation 'DROP COLUMN' cannot be performed on object 'ATDC_5(B)' because VIEW 'ATDC_VW_1' is dependent on that object. Does it seem correct that: a) RESTRICT processing should consider an index on a column to be a dependent object and fail the DROP COLUMN if the column is used in an index? b) CASCADE processing should cascade the DROP COLUMN to include dropping a view which uses the column that is dropped? thanks, bryan
