alamb commented on code in PR #13717:
URL: https://github.com/apache/datafusion/pull/13717#discussion_r1893083600
##########
datafusion/core/src/catalog_common/information_schema.rs:
##########
@@ -406,6 +406,7 @@ fn get_udf_args_and_return_types(
.into_iter()
.map(|arg_types| {
// only handle the function which implemented
[`ScalarUDFImpl::return_type`] method
+ #[allow(deprecated)]
Review Comment:
> Let's turn the question around. What problems would return_type_with_args
be solving?
In my mind there are two usecases for `return_type`:
1. LogicalPlanning (aka the analyzer and type coercion, etc) when you have
`Exprs`
2. PhysicalPlanning (aka physical optimizers)
As I understood the problem is that some things in the LogicalPlanner do
things with the exprs (like determining the type of the arguments)
I agree with the "it is not clear when you get arguments in what contexts"
Maybe we could make this explicit with an enum like the following 🤔
```rust
/// Information about arguments when calling `return_type`
enum ArgumentInfo {
LogicalPlanning {
args: &[Expr],
schema: &dyn ExprSchema
},
PhysicalExecution,
...
}
struct ReturnTypeArgs {
// Argument information
arg_info: ArgumentInfo,
// argument DataTypes
arg_types: &[DataType],
}
```
--
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
