DROP CASCADE onto virtual columns in same table (Pending)¶

When you drop a column with ALTER TABLE … DROP COLUMN and specify the CASCADE keyword, Snowflake now also drops any virtual columns in the same table that depend on the dropped column, together with the base column. Previously, CASCADE had no effect in this case and the statement was blocked.

Before the change:

Dropping a column that a virtual column depends on was blocked, whether or not you specified CASCADE. The statement failed with an error instructing you to drop the dependent virtual column first:

Copy code

CREATE OR REPLACE TABLE t (a INT, b INT, vc INT AS (a + b));

ALTER TABLE t DROP COLUMN a CASCADE;

011208 (2BP01): SQL compilation error:
Cannot drop column 'A' because virtual column 'VC' depends on it

To drop the column, you first had to drop each dependent virtual column explicitly.

After the change:

When the 2026_06 behavior change bundle is enabled in your account, ALTER TABLE … DROP COLUMN … CASCADE drops the column along with any virtual columns that depend on it, directly or indirectly:

Copy code

CREATE OR REPLACE TABLE t (a INT, b INT, vc INT AS (a + b));

-- Drops both column A and the dependent virtual column VC:
ALTER TABLE t DROP COLUMN a CASCADE;

DROP COLUMN without CASCADE is unchanged: it still fails when the column has a dependent virtual column, so you must drop the dependent columns first.

How to update your code¶

Because CASCADE now drops dependent virtual columns instead of blocking the statement, ALTER TABLE … DROP COLUMN … CASCADE can remove more columns than before. Review any automation or scripts that drop columns with CASCADE to confirm the additional drops are intended.

If a virtual column is dropped unintentionally, you can restore an earlier version of the table with Time Travel, provided Time Travel retention is enabled for the table.

Ref: 2382