anlinc commented on code in PR #14553:
URL: https://github.com/apache/datafusion/pull/14553#discussion_r1953345644
##########
datafusion/expr/src/logical_plan/builder.rs:
##########
@@ -1090,11 +1090,31 @@ impl LogicalPlanBuilder {
group_expr: impl IntoIterator<Item = impl Into<Expr>>,
aggr_expr: impl IntoIterator<Item = impl Into<Expr>>,
) -> Result<Self> {
- let group_expr = normalize_cols(group_expr, &self.plan)?;
+ self._aggregate(group_expr, aggr_expr, true)
+ }
+
+ pub fn aggregate_without_implicit_group_by_exprs(
+ self,
+ group_expr: impl IntoIterator<Item = impl Into<Expr>>,
+ aggr_expr: impl IntoIterator<Item = impl Into<Expr>>,
+ ) -> Result<Self> {
+ self._aggregate(group_expr, aggr_expr, false)
+ }
+
+ fn _aggregate(
Review Comment:
> Intuitively it feels like the constructed logical plan shouldn't do this
kind of magic, but the analyzer/optimizer can if it makes things faster to
execute.
We're on the same page here. My first approach actually was to move this out
of the LogicalPlanBuilder and into an Analyzer rule.
However, I abandoned that because it would break the supported functionality
that allows you to project unique expressions that are not part of the grouping
expressions set.
Analyzer rules are run after the logical plan has been constructed. The
checks in place to validate projection references:
https://github.com/apache/datafusion/blob/main/datafusion/sql/src/select.rs#L803
happens before that.
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
