github-actions[bot] commented on code in PR #64251:
URL: https://github.com/apache/doris/pull/64251#discussion_r3375105953
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/SubExprAnalyzer.java:
##########
@@ -137,8 +137,9 @@ public Expression visitScalarSubquery(ScalarSubquery
scalar, T context) {
// so when creating LogicalApply node, we don't need to add AssertTrue
function
boolean limitOneIsEliminated = false;
if (isCorrelated) {
- if (analyzedSubqueryPlan instanceof LogicalLimit) {
- LogicalLimit limit = (LogicalLimit) analyzedSubqueryPlan;
+ if (analyzedSubqueryPlan instanceof LogicalLimit
+ && !(((LogicalLimit<?>) analyzedSubqueryPlan).child()
instanceof LogicalSort)) {
Review Comment:
This only protects the direct `LogicalLimit(LogicalSort(...))` shape. If the
ordered input is wrapped before the limit, the old unsafe path remains: for
example a scalar subquery shaped like `select c2 from (select c2 from
correlated_scalar_t2 where correlated_scalar_t1.c1 = correlated_scalar_t2.c1
order by c2) s limit 1` has the `LIMIT 1` above a subquery alias/project rather
than an immediate `LogicalSort`. This branch will eliminate the limit and set
`limitOneIsEliminated`, while `validateNodeInfoList` later allows
`LOGICAL_SORT`, so the query can be accepted with the top-1 ordering semantics
removed. Please reject any `LOGICAL_LIMIT` above a correlated node whose
subtree preserves an order, or move this into validation instead of checking
only the immediate child.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
