alamb commented on a change in pull request #7988:
URL: https://github.com/apache/arrow/pull/7988#discussion_r472213122
##########
File path: rust/datafusion/src/logicalplan.rs
##########
@@ -363,8 +335,6 @@ pub enum Expr {
name: String,
/// List of expressions to feed to the functions as arguments
args: Vec<Expr>,
- /// The `DataType` the expression will yield
- return_type: DataType,
Review comment:
I think (eventually) `AggregateFunction` store its return type will be
important for user defined aggregates, but for now hard coding the rules to
compute the output type based on the input type for built in aggregates is a
good idea.
Perhaps we can special case UDAs in a follow on PR with something such as
`UserDefinedAggregateFunction` rather than making `AggregateFunction` work for
both built in aggregates and user defined ones
##########
File path: rust/datafusion/src/logicalplan.rs
##########
@@ -379,7 +349,48 @@ impl Expr {
Expr::Literal(l) => l.get_datatype(),
Expr::Cast { data_type, .. } => Ok(data_type.clone()),
Expr::ScalarFunction { return_type, .. } =>
Ok(return_type.clone()),
- Expr::AggregateFunction { return_type, .. } =>
Ok(return_type.clone()),
+ Expr::AggregateFunction { name, args, .. } => {
+ match name.to_uppercase().as_str() {
+ "MIN" | "MAX" => args[0].get_type(schema),
+ "SUM" => match args[0].get_type(schema)? {
+ DataType::Int8
+ | DataType::Int16
+ | DataType::Int32
+ | DataType::Int64 => Ok(DataType::Int64),
+ DataType::UInt8
+ | DataType::UInt16
+ | DataType::UInt32
+ | DataType::UInt64 => Ok(DataType::UInt64),
+ DataType::Float32 => Ok(DataType::Float32),
Review comment:
why not Float64 here (as Int32 --> Int64 for integers)?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
