Skip to content

Validate data-modifying CTEs through statement validators - #2578

Merged
manticore-projects merged 1 commit into
JSQLParser:masterfrom
minleejae:fix/data-modifying-cte-validation
Sep 11, 2026
Merged

Validate data-modifying CTEs through statement validators#2578
manticore-projects merged 1 commit into
JSQLParser:masterfrom
minleejae:fix/data-modifying-cte-validation

Conversation

@minleejae

Copy link
Copy Markdown
Contributor

Validating WITH x AS (DELETE FROM foo RETURNING id) SELECT * FROM x throws ClassCastException because the CTE validator assumes every body is a SELECT. INSERT and UPDATE bodies fail the same way.

Route the body through WithItem.accept(StatementVisitor, context) and the existing statement validators. This removes the SELECT-only cast and reuses the validation and error collection already implemented for each statement type. CTE feature checks and column-list traversal remain in the select validator.

Validation: full Gradle check and Maven verify; INSERT/UPDATE/DELETE CTEs under restricted and permissive capabilities, ordinary/recursive/nested SELECT CTEs, multiple bodies, following statements and RETURNING expression validation. Restricted DML produces validation errors instead of runtime exceptions.

Fixes #2574.

@manticore-projects
manticore-projects merged commit 7252121 into JSQLParser:master Sep 11, 2026
9 checks passed
@manticore-projects

Copy link
Copy Markdown
Contributor

Thank you much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Validation.validate throws ClassCastException on a data-modifying CTE (WithItem.getSelect on ParenthesedDelete)

2 participants