github-actions[bot] commented on code in PR #64778:
URL: https://github.com/apache/doris/pull/64778#discussion_r3465465899


##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/SubExprAnalyzer.java:
##########
@@ -433,6 +444,11 @@ private LogicalAggregate 
validateNodeInfoList(List<PlanNodeCorrelatedInfo> nodeI
                         case LOGICAL_JOIN:
                             throw new AnalysisException(
                                     "access outer query's column before join 
is not supported");
+                        case LOGICAL_UNION:

Review Comment:
   This rejection is currently only reachable from `visitScalarSubquery`, 
because that is the only visitor that calls `validateSubquery()`. The same 
unsupported shape can still be built through correlated `EXISTS` or `IN`, for 
example:
   
   ```text
   Filter(EXISTS)
     LogicalApply(correlationSlot=[o.c1], correlationFilter=empty)
       Scan o
       LogicalUnion
         Filter(i.c1 = o.c1)
         Filter(i.c1 = o.c1)
   ```
   
   `CorrelateApplyToUnCorrelateApply` has rules for filter/project/aggregate 
right-child shapes, but no set-operation rule, so the correlation predicate 
stays under the union. `ExistsApplyToJoin`/`InApplyToJoin` then see a 
correlated apply with no `correlationFilter` and take the uncorrelated path, 
leaving the right side with an outer slot instead of a join predicate. Please 
either run the same structural rejection for correlated `EXISTS`/`IN` 
subqueries, or add set-operation decorrelation support before `ApplyToJoin`.



##########
regression-test/suites/query_p0/subquery/correlated_scalar_subquery.groovy:
##########
@@ -256,6 +256,26 @@ suite("correlated_scalar_subquery") {
         exception "access outer query column"
     }
 
+    test {
+        sql """
+              SELECT correlated_scalar_t1.c1 FROM correlated_scalar_t1 WHERE 
correlated_scalar_t1.c1 = (SELECT correlated_scalar_t1.c1);
+        """
+        exception "access outer query's column in project is not supported"
+    }
+
+    test {

Review Comment:
   The production change now rejects three set-operation plan types 
(`LOGICAL_UNION`, `LOGICAL_INTERSECT`, and `LOGICAL_EXCEPT`), but the new 
regression only exercises `UNION ALL`. Please add negative cases for correlated 
scalar subqueries crossing `INTERSECT` and `EXCEPT` as well, so the full new 
switch coverage is protected.



-- 
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]

Reply via email to