mihaibudiu commented on code in PR #5052:
URL: https://github.com/apache/calcite/pull/5052#discussion_r3486933527
##########
core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java:
##########
@@ -5599,6 +5601,11 @@ protected RelDataType validateSelectList(final
SqlNodeList selectItems,
// First pass, ensure that aliases are unique. "*" and "TABLE.*" items
// are ignored.
+ // Rewrite scalar sub-queries whose single select item is an aggregate
+ // over outer columns. The aggregate belongs to the outer query per SQL
+ // standard.
+ rewriteOuterAggregatesInSelectList(select);
Review Comment:
call this handleOuterAggregate, and make the function reject it if not in a
suitable conformance mode.
##########
core/src/test/resources/sql/agg.iq:
##########
@@ -4301,4 +4301,128 @@ GROUP BY GROUPING SETS ((deptno), ());
!ok
+# [CALCITE-6104] Aggregate function that references outer column should be
evaluated in outer query
+# The expected results below have been verified in PostgreSQL by running
Review Comment:
You say that postgres accepts these queries, then why do you have to modify
the queries to run them on postgres? I couldn't run them as written in Postgres.
##########
core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java:
##########
@@ -5658,6 +5665,277 @@ protected RelDataType validateSelectList(final
SqlNodeList selectItems,
return typeFactory.createStructType(fieldList);
}
+ /**
+ * Rewrites scalar sub-queries in the SELECT list whose single select item is
+ * an aggregate function whose arguments reference only outer columns. Per
the
+ * SQL standard, such aggregates belong to the outer query.
+ *
+ * <p>The algorithm is:
+ * <ol>
+ * <li>For each item in the SELECT list, check whether it is a scalar
+ * sub-query, optionally wrapped in {@code AS} or {@code WITH}.
+ * <li>Inside the sub-query, require the SELECT list to contain exactly one
+ * item, and that item to be an aggregate function call.
+ * <li>Require every argument of the aggregate to reference only columns from
+ * the outer query (no inner columns), and to contain no nested sub-queries.
+ * <li>If all conditions hold, lift the aggregate out of the sub-query: keep
+ * the aggregate in the outer SELECT list, and replace the original sub-query
+ * with {@code (SELECT 1 FROM ... LIMIT 1)}. The result is equivalent because
+ * the scalar sub-query contributes a factor of one per outer row, while the
+ * aggregate is evaluated over the outer rows.
+ * <li>If the outer query becomes an aggregate query as a result, upgrade its
+ * SELECT clause scope from {@link SelectScope} to
+ * {@link AggregatingSelectScope}.
+ * </ol>
+ *
+ * <p>For example,
+ * <blockquote><pre>
+ * WITH aa(a) AS (VALUES 1, 2, 3),
+ * t(x) AS (VALUES 10, 20, 30)
+ * SELECT (SELECT sum(a) FROM t LIMIT 1) FROM aa
+ * </pre></blockquote>
+ * is rewritten to
+ * <blockquote><pre>
+ * WITH aa(a) AS (VALUES 1, 2, 3),
+ * t(x) AS (VALUES 10, 20, 30)
+ * SELECT sum(a) * (SELECT 1 FROM t LIMIT 1) FROM aa
Review Comment:
This rewrite will only work for numeric aggregates on types which have a
multiplication operation
##########
core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java:
##########
@@ -5658,6 +5665,277 @@ protected RelDataType validateSelectList(final
SqlNodeList selectItems,
return typeFactory.createStructType(fieldList);
}
+ /**
+ * Rewrites scalar sub-queries in the SELECT list whose single select item is
+ * an aggregate function whose arguments reference only outer columns. Per
the
+ * SQL standard, such aggregates belong to the outer query.
+ *
+ * <p>The algorithm is:
+ * <ol>
+ * <li>For each item in the SELECT list, check whether it is a scalar
+ * sub-query, optionally wrapped in {@code AS} or {@code WITH}.
+ * <li>Inside the sub-query, require the SELECT list to contain exactly one
+ * item, and that item to be an aggregate function call.
+ * <li>Require every argument of the aggregate to reference only columns from
+ * the outer query (no inner columns), and to contain no nested sub-queries.
+ * <li>If all conditions hold, lift the aggregate out of the sub-query: keep
+ * the aggregate in the outer SELECT list, and replace the original sub-query
+ * with {@code (SELECT 1 FROM ... LIMIT 1)}. The result is equivalent because
+ * the scalar sub-query contributes a factor of one per outer row, while the
+ * aggregate is evaluated over the outer rows.
+ * <li>If the outer query becomes an aggregate query as a result, upgrade its
+ * SELECT clause scope from {@link SelectScope} to
+ * {@link AggregatingSelectScope}.
+ * </ol>
+ *
+ * <p>For example,
+ * <blockquote><pre>
+ * WITH aa(a) AS (VALUES 1, 2, 3),
+ * t(x) AS (VALUES 10, 20, 30)
+ * SELECT (SELECT sum(a) FROM t LIMIT 1) FROM aa
Review Comment:
Is the LIMIT 1 needed here?
--
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]
