SQL CASCADED

What is the SQL CASCADED keyword used for?

Keyword used with WITH CHECK OPTION to enforce that updates through a view satisfy all conditions in the entire view hierarchy, not just the current view.

Welcome to the Galaxy, Guardian!
You'll be receiving a confirmation email

Follow us on twitter :)

Oops! Something went wrong while submitting the form.

Compatible dialects for SQL CASCADED:

SQL CASCADED Full Explanation

CASCADED appears in the WITH CHECK OPTION clause of CREATE VIEW and ALTER VIEW statements. When a view is declared WITH CASCADED CHECK OPTION, every row inserted or updated through that view must satisfy the WHERE clauses of the view itself and of every underlying updatable view referenced in its definition. If any condition is violated, the statement is rejected. CASCADED therefore propagates data-integrity rules down the full chain of nested views, preventing users from bypassing restrictions by updating through higher-level views. If CASCADED (or its synonym CASCADE in some dialects) is omitted, many engines default to LOCAL, meaning only the current view’s predicate is enforced. CASCADED is defined in the SQL standard and implemented by several relational databases, though some use CASCADE, and others always behave as if CASCADED were specified. The keyword has no effect outside WITH CHECK OPTION.

SQL CASCADED Syntax

CREATE VIEW view_name AS
SELECT column_list
FROM base_or_view
WHERE predicate
WITH CASCADED CHECK OPTION;

SQL CASCADED Parameters

Example Queries Using SQL CASCADED

-- Base view restricting sensitive rows
CREATE VIEW hr.confidential_employees AS
SELECT id, name, salary
FROM hr.employees
WHERE is_confidential = FALSE
WITH CASCADED CHECK OPTION;

-- Higher-level view that further limits rows
CREATE VIEW hr.low_risk_employees AS
SELECT *
FROM hr.confidential_employees
WHERE risk_score < 50
WITH CASCADED CHECK OPTION;

-- Attempt to update through the top view that violates either predicate
UPDATE hr.low_risk_employees
SET risk_score = 70
WHERE id = 1001;

Expected Output Using SQL CASCADED

The UPDATE is rejected
Error message indicates that the row does not satisfy the CHECK OPTION for view hr
low_risk_employees (or a dependent view) because risk_score would exceed 50, violating the cascaded condition chain

Use Cases with SQL CASCADED

Enforcing business rules across multiple layers of nested views
Preventing privilege escalation where users can see fewer rows through a view but still modify hidden rows
Maintaining consistent data security policies when exposing simplified or aggregated views to applications

Common Mistakes with SQL CASCADED

Confusing CASCADED with CASCADE (used in DROP/ALTER statements)
Assuming CASCADED is default in all databases; some default to LOCAL
Expecting CASCADED to work outside WITH CHECK OPTION
Using CASCADED on a non-updatable view; the statement will fail

First Introduced In

SQL-92

Frequently Asked Questions

What is the difference between CASCADED and LOCAL?

CASCADED validates every predicate in the entire chain of underlying views, whereas LOCAL validates only the predicate defined in the view being updated.

Is CASCADED mandatory in WITH CHECK OPTION?

No. Omitting both CASCADED and LOCAL defaults to engine-specific behavior (LOCAL in PostgreSQL, CASCADED in MySQL). Explicitly stating CASCADED guarantees cross-database clarity.

Does CASCADED affect SELECT statements?

No. CASCADED only influences INSERT, UPDATE, or DELETE operations executed through the view. SELECT statements are unchanged.

Which databases implement CASCADED?

PostgreSQL, MySQL, MariaDB, and IBM Db2 support the keyword. SQL Server ignores it and Oracle behaves as if CASCADED were always in effect when WITH CHECK OPTION is used.