cloud-fan commented on code in PR #38888:
URL: https://github.com/apache/spark/pull/38888#discussion_r1040774763
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/Analyzer.scala:
##########
@@ -689,9 +687,26 @@ class Analyzer(override val catalogManager: CatalogManager)
// For CUBE/ROLLUP expressions, to avoid resolving repeatedly, here we
delete them from
// groupingExpressions for condition resolving.
val aggForResolving = aggregate.copy(groupingExpressions = groupByExprs)
+ // HACK ALTER! Ideally we should only resolve GROUPING SETS + HAVING
when the having condition
+ // is fully resolved, similar to the rule `ResolveAggregateFunctions`.
However, Aggregate
+ // with GROUPING SETS is marked as unresolved and many analyzer rules
can't apply to
+ // UnresolvedHaving because its child is not resolved. Here we
explicitly resolve columns
+ // and subqueries of UnresolvedHaving so that the rewrite works in most
cases.
Review Comment:
This follows the previous code and has the same issues as before. For
example:
```
create temp view t as select 1 a, 2 b, 3d c;
select max(a) from t group by grouping sets ((b, c), (b + c)) having b + c >
0;
org.apache.spark.sql.AnalysisException: Column 'b' does not exist. Did you
mean one of the following? [max(a)]
```
This fails because `b + c` needs type coercion to be resolved, which will
never happen as `Aggregate` with GROUPING SETS is marked as unresolved. Then
Spark never knows that `b + c` is actually the grouping expression and can't
rewrite HAVING.
--
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]
