alamb opened a new issue, #10534:
URL: https://github.com/apache/datafusion/issues/10534
> @alamb Do you think we should also rewrite the array
operator to function in parser step? It is currently in optimizer step. I think
the downside of moving array rewrite in parser step is that if any user expects
different array function with the same syntax, then they can't do it since we
don't have "user-defined" parser mechanism now. But the benefit is that we can
eliminate intermediate binary expression.
I agree that changing the parser to insert a call to get field access
directly is a good idea (and would be consistent and allow us to remove
`Expr::GetFieldAccess`
> Have you thought about "user-defined" parser idea before, the way that
user can define their own expression to get from the syntax? Is it useful in
production? 🤔
One thing I have thought about is changing the hard coded lookup of function
names from a pattern like this
https://github.com/apache/datafusion/blob/fc34dacdb9842cde4d056d5a659796ede4ae5e74/datafusion/sql/src/expr/value.rs#L144-L150
To be something more structured
```rust
pub trait PlannerFunctions {
/// return the UDF to use for creating arrays ("make_array") by default:
fn make_array(&self) -> Result<ScalarUDF>;
...
// similar functions for other built in functions
}
```
And then instead of
```rust
if let Some(udf) = self.context_provider.get_function_meta("make_array") {
Ok(Expr::ScalarFunction(ScalarFunction::new_udf(udf, values)))
} else {
not_impl_err!(
"array_expression featrue is disable, So should implement
make_array UDF by yourself"
)
}
```
The planner might look like
```rust
let udf = self.planner_functions.make_array()?;
Ok(Expr::ScalarFunction(ScalarFunction::new_udf(udf, values)))
```
But I haven't had a usecase to do that myself yet
_Originally posted by @alamb in
https://github.com/apache/datafusion/issues/10374#issuecomment-2111006004_
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
