fix(plan): handle correlated scalar outer projections#25920
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
@gouhongshen Addressed in commit |
XuPeng-SH
left a comment
There was a problem hiding this comment.
Reviewed latest head 20ecd59. No blocking findings.
The prior requested changes are resolved: OFFSET/rank/dynamic or zero LIMIT shapes now fall back before mutation; literal LIMIT 1 uses MARK existence semantics; LIMIT >= 2 removes the misplaced limit while SINGLE join preserves per-outer-row cardinality; synthesized CASE is gated by semantic type equality.
Verified with full pkg/sql/plan tests, focused regressions 5x, go build, go vet, and an exact-head mo-service execution matrix covering empty/one/multi-row inputs, NULLs, duplicate outer rows, DISTINCT, LIMIT 1, LIMIT 2, and proper 1242/21000 multi-row errors. Current CI has no failures (three jobs are still running).
gouhongshen
left a comment
There was a problem hiding this comment.
Codex automated review
No blocking or non-blocking findings remain. The latest discussion is supported by the current code: prior LIMIT/OFFSET and CASE type regressions are resolved, while unsupported CASE types conservatively retain pre-existing behavior without introducing a regression. Current-head CI is green; local focused tests could not run because libmo.dylib is absent.
Merge Queue Status
This pull request spent 1 hour 47 minutes 16 seconds in the queue, with no time running CI. Waiting for
All conditions
ReasonPull request #25920 has been dequeued Pull request from fork cannot be queued. This pull request comes from a fork, and Mergify needs the author's permission to update its branch.
Failing checks:
HintYou should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. Tick the box to put this pull request back in the merge queue (same as
|
What type of PR is this?
Which issue(s) this PR fixes:
issue #23062
What this PR does / why we need it:
Direct outer-column references projected by correlated scalar subqueries could remain in the executable right subtree, causing internal errors and incorrect behavior through DISTINCT and ORDER BY/LIMIT wrappers.
This change:
Testing