alamb commented on code in PR #2446:
URL: https://github.com/apache/arrow-datafusion/pull/2446#discussion_r867982502
##########
datafusion/expr/src/expr_schema.rs:
##########
@@ -198,6 +202,11 @@ impl ExprSchemable for Expr {
let data_type = expr.get_type(input_schema)?;
get_indexed_field(&data_type, key).map(|x| x.is_nullable())
}
+ Expr::GroupingSet(_) => {
+ // grouping sets do not really have the concept of nullable
and do not appear
Review Comment:
I wonder if it is worth considering representing the grouping sets in a more
specific way (like maybe a specific list on `LogicalPlan::Aggregrate`) rather
than an `Expr` that can appear anywhere
```rust
enum GroupingExpr {
Expr(Expr),
GroupingSet(GroupingSet),
}
/// Aggregates its input based on a set of grouping and aggregate
/// expressions (e.g. SUM).
#[derive(Clone)]
pub struct Aggregate {
/// The incoming logical plan
pub input: Arc<LogicalPlan>,
/// Grouping expressions
pub group_expr: Vec<AggExprs>,
/// Aggregate expressions
pub aggr_expr: Vec<Expr>,
/// The schema description of the aggregate output
pub schema: DFSchemaRef,
}
```
Or something?
##########
datafusion/expr/src/expr.rs:
##########
@@ -249,6 +249,24 @@ pub enum Expr {
Wildcard,
/// Represents a reference to all fields in a specific schema.
QualifiedWildcard { qualifier: String },
+ /// List of grouping set expressions. Only valid in the context of an
aggregate
Review Comment:
While reviewing this PR I was wondering how you aim to plan these queries
it seems like a simple way would be to expand them to a set of `UNION ALL`
queries, though then we will likely do the same input query many times which
may be unideal.
Anyhow, I am looking forward to the next installment
--
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]
