planner: fix a bug that caused OrderBy correlated subquery can't find the outer schema

[rebelice]

What problem does this PR solve?

Issue Number: close #26945

Problem Summary:

What is changed and how it works?

Before this PR, when we build OrderBy correlated subquery, we will find the outer column from outerSchemas and outerNames. But the outerSchemas and outerNames will be pruned by BuildSelect. We may not find columns in some cases.

Here we use allSchemas and allNames instead of outerSchemas and outerNames. Because allSchemas and allNames will not be pruned.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

planner: fix a bug that caused OrderBy correlated subquery can't find the outer schema

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[winoros]

emm, leave me some time to re-think a little(
The changing scope is larger than the SORT.

[ti-chi-bot]

@rebelice: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kolbe]

@winoros any update to this issue?

[yudongusa]

We apologize for the delay of the fix as some complication were found during the PR review. We're working on the fix revision and will provide the final fix soon.

[winoros]

Duplicated

[winoros]

After I go through the codes.
What you should modify is havingWindowAndOrderbyExprResolver.

For example, select a from t order by b. The b doesn't appear in the select fields. But we can also execute the SQL successfully. This is because this visitor detects the b in order by item and rewrite it to select a from (select a, b from t order by b).

func (b *PlanBuilder) resolveHavingAndOrderBy(sel *ast.SelectStmt, p LogicalPlan) (
	map[*ast.AggregateFuncExpr]int, map[*ast.AggregateFuncExpr]int, error) {
	extractor := &havingWindowAndOrderbyExprResolver{
		p:            p,
		selectFields: sel.Fields.Fields,
		aggMapper:    make(map[*ast.AggregateFuncExpr]int),
		colMapper:    b.colMapper,
		outerSchemas: b.outerSchemas,
		outerNames:   b.outerNames,
	}
	stepping into group by, order by and having.
	sel.Fields.Fields = extractor.selectFields
	return ...
}

So we just need to modify the behavior when the extractor goes into the order by clause. This changes would be more stable.

[AilinKid]

resolved by #26945