docs(parity): file P35 (#n positional refs) and P36 (expr_N column naming) - #60
Merged
Conversation
…ming) Both raised 2026-08-31 from the question "does DuckDB support `WITH wrapped AS (SELECT ...) SELECT 1, 2, 5 FROM wrapped`". Probed against the pinned DuckDB 1.5.5; neither is filed with a decision, deliberately. The question has two readings and only one is a gap. `SELECT 1, 2, 5` is NOT positional in either engine — those are constants, and we already agree with DuckDB on the values. `SELECT #1, #2, #5` is the positional form, and we reject it. Worth writing down because the first reading is a live trap. P35 is a DuckDB extension, not standard SQL, so the "follow the reference engine" default explicitly does not apply — it needs arguing on usefulness or marking WON'T FIX. Recorded what the probe established so that argument does not start from scratch: `#n` resolves against the OUTPUT list in ORDER BY (same rule P16 just implemented), `#1` already lexes as Identifier("#1") so no lexer change is needed, and the `#tmp` collision is `#`+digits vs `#`+letters. P36 is cheaper but carries a trap of its own: it changes no values and could still churn every captured FORMAL expectation, since those hold column names. Measure that before starting. It also cannot be pinned in an existing tier — the convention there is to alias computed columns so the comparison aligns, so it needs a case written specifically to break that convention. No corpus cases yet for either; the contract is unchanged at 139 AGREE of 168. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TmQRCdZUn3RYqyVFoeKRsY
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.
Docs-only. No code, no corpus cases, no contract change (139 AGREE of 168, verified).
Both came out of the question "does DuckDB support
WITH wrapped AS (SELECT ...) SELECT 1, 2, 5 FROM wrapped", probed against the pinned DuckDB 1.5.5.The question has two readings; only one is a gap
SELECT 1, 2, 51,2,5expr_1..3SELECT #1, #2, #5Column '#1' not foundWorth writing down because the first row is a live trap —
SELECT 1, 2, 5is not positional in either engine, and we already agree with DuckDB on its values.P35 —
#npositional column referencesFiled with the decision left open on purpose. This is a DuckDB extension, not standard SQL, so the doc's own "where the standard leaves a choice open, follow the reference engine" default does not apply — it has to be argued on usefulness or marked WON'T FIX.
Recorded what the probe established so that argument doesn't start cold:
#nis not uniform across clauses. InORDER BYit resolves against the output list, not the source —SELECT #1, #3 FROM t ORDER BY #3errors "ORDER term out of range — should be between 1 and 2". Same rule P16 just implemented, which is the natural place to hang it.#1already arrives asIdentifier("#1")via the catch-all (the route;took before P13 stage 1).#tmpcollision is narrow:#+digits vs#+letters. The sevenstarts_with('#')sites are listed as the thing to check first.P36 — unaliased expression column naming
SELECT score*2, UPPER(team)→ DuckDB names them(score * 2)/upper(team); we useexpr_1/expr_2.Cheaper to implement, with a trap of its own: it changes no values anywhere and could still churn every captured FORMAL expectation, since those hold column names — the P21 pattern with none of the payoff of finding a bug. Measure the churn first.
It also can't be pinned in an existing tier: the convention there is to alias computed columns so the comparison aligns (the harness says so in its own diff output), so it needs a case written specifically to break that convention, and a note saying why.
🤖 Generated with Claude Code
https://claude.ai/code/session_01TmQRCdZUn3RYqyVFoeKRsY