bug: 'cascade' and 'restrict' are not handled by drop view

[neverchanje]

Describe the bug

No response

To Reproduce

dev=> create table t ();
CREATE_TABLE
dev=> create view v as select * from t;
CREATE_VIEW

dev=> drop view if exists v cascade;
DROP_VIEW
dev=> \dt
               List of relations
   Schema   |       Name       | Type  | Owner
------------+------------------+-------+-------
 public     | t                | table | root
 rw_catalog | rw_ddl_progress  | table | root
 rw_catalog | rw_meta_snapshot | table | root
(3 rows)

When I specify 'cascade' when dropping 'v', the table 't' still exists.

dev=> drop view if exists v restrict;
DROP_VIEW

Same for restrict.

Expected behavior

Disallow these two keywords or handle them. The latter is preferable.

Additional context

No response

[BugenZhao]

Agree that we should at least report "unimplemented" instead of silently ignoring that.

[chenzl25]

I tried to optimize our DBT adapter recently and found that Drop cascade is crucial to the user experience, otherwise it would fail to run dbt run the second time. I think we should support it.

[yezizp2012]

Done by #11250 .