findepi commented on code in PR #13756:
URL: https://github.com/apache/datafusion/pull/13756#discussion_r1888428810
##########
datafusion/functions-nested/src/extract.rs:
##########
@@ -993,3 +993,84 @@ where
let data = mutable.freeze();
Ok(arrow::array::make_array(data))
}
+
+#[cfg(test)]
+mod tests {
+ use super::array_element_udf;
+ use arrow_schema::{DataType, Field};
+ use datafusion_common::{Column, DFSchema, ScalarValue};
+ use datafusion_expr::expr::ScalarFunction;
+ use datafusion_expr::{cast, Expr, ExprSchemable};
+ use std::collections::HashMap;
+
+ #[test]
+ fn test_array_element_return_type() {
+ let complex_type = DataType::FixedSizeList(
Review Comment:
> How about we compute the `return_type` when the function is created, and
`get_type` read the value.
I like the idea _in principle_.
It should be combined with a new ScalarUDFImpl sub-trait that doesn't have
return type-related methods at all, since they are not to be used once the plan
is constructed.
> The reason is because we can't guarantee the input is already coerced.
in a _logical plan_ we can.
My understanding is that coercing analyzer also calls the `get_type`
functions.
It can be solved by changing how the coercing analyzer tracks its internal
state.
But the real problem is that same types, the `LogicalPlan` & `Expr`, have
two meanings: syntactic and semantic. So in the code we go back and forth about
what should and what cannot be guaranteed for an `Expr` or `LogicalPlan`
instance.
--
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
