xuzifu666 commented on code in PR #4983:
URL: https://github.com/apache/calcite/pull/4983#discussion_r3338261280
##########
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableAggregateBase.java:
##########
@@ -145,6 +146,32 @@ protected void implementLambdaFactory(BlockBuilder builder,
requireNonNull(agg.accumulatorAdder,
"agg.accumulatorAdder")))));
continue;
}
+ // Check if all collation field indices are within the input row type
bounds.
+ // When using LISTAGG(DISTINCT col1) WITHIN GROUP (ORDER BY col2)
where col2 is not
+ // a GROUP BY column, col2's index may exceed the re-grouped input row
type bounds.
+ // In such cases, we fall back to non-sorted aggregation instead of
crashing.
+ boolean validCollation = true;
+ for (final RelFieldCollation fieldCollation :
agg.call.collation.getFieldCollations()) {
+ if (fieldCollation.getFieldIndex() >=
inputPhysType.getRowType().getFieldCount()) {
+ validCollation = false;
+ break;
+ }
+ }
+
+ if (!validCollation) {
Review Comment:
There are two options:
1. Complete Fix: add `ORDER BY` columns to the re-grouped input, requires
architectural changes to aggregate planning,changes query semantics, potential
impact on other parts.This is a large-scale refactoring;
2. Graceful Degradation(current way): returns correct results without
crashes, loses sorting information, but doesn't crash.This is a rare
scenario:only occurs with ```LISTAGG(DISTINCT ...) WITHIN GROUP (ORDER BY
non-group-column)```.
According the conditions I choose the second way. So do you think my current
plan is reasonable?
--
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]
