fix: apply recursive CTE column-list aliases to the static term#23098
Open
tomsanbear wants to merge 1 commit into
Open
fix: apply recursive CTE column-list aliases to the static term#23098tomsanbear wants to merge 1 commit into
tomsanbear wants to merge 1 commit into
Conversation
`WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 10)` failed to plan with `Schema error: No field named n. Valid fields are t."Int64(1)".`. The CTE's declared column-list names were applied (via `apply_table_alias`) only after the whole CTE plan was built, but the recursive working relation is derived from the schema of the static term before that, so the self-reference could never resolve the declared names. Apply the column-list aliases to the static term inside `recursive_cte`, before the work table is created, so the working relation and the self-reference expose the declared names. The relation-name alias is still added by the caller; on the recursive path the column re-alias is skipped to avoid a redundant projection on top of the `RecursiveQuery` node. The non-UNION fallback applies the aliases directly. Non-recursive CTEs are unchanged. Adds sqllogictest coverage for single- and multi-column column-list recursive CTEs, UNION (DISTINCT), and the column/alias-count mismatch error.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
WITH RECURSIVE t(n) AS (...)failed to plan because the CTE's declared column-list names (thet(n)part) were never applied to the recursive working relation. They were applied (viaapply_table_alias) only after the whole CTE plan was built, but the working table is derived from the static term's schema before that — so the self-reference couldn't resolve the declared names and planning failed withSchema error: No field named n. Valid fields are t."Int64(1)".. PostgreSQL and DuckDB accept the query; aliasing inside the staticSELECT(SELECT 1 AS n) was the only workaround.What changes are included in this PR?
Apply the column-list aliases to the static term inside
recursive_cte(), before the work table is created, so the working relation and the self-reference carry the declared names. The caller now applies only the relation-name alias on the recursive path (the columns are already applied), avoiding a redundant projection on top of theRecursiveQuerynode. The non-UNION fallback applies the aliases directly; non-recursive CTEs are unchanged. A column/alias-count mismatch is now reported at the static term — a clearer error than the previous "No field named …".Are these changes tested?
Yes, added
cte.sltcases for single- and multi-column column-list recursive CTEs (asserting the recursion produces the expected rows),UNION (DISTINCT), the arity-mismatch error, and anEXPLAINlocking the plan shape (no extra projection overRecursiveQuery).Are there any user-facing changes?
WITH RECURSIVE t(n) AS (...)and multi-column column lists now plan and execute correctly, matching PostgreSQL/DuckDB. No API changes.Note: this pull request was created together with AI tools (claude code), the full diff was reviewed by myself in full prior to submission