alamb commented on PR #13527:
URL: https://github.com/apache/datafusion/pull/13527#issuecomment-2789191368
I keep thinking about this PR in the back of my head. The idea of being able
to customize functions based on configuration options makes total sense to me,
but having to plumb it down all the way through to execution is so disruptive
on the APIs and adds non trivial overhead to the whole system for just a few
functions
One alternate idea I had was to store whatever setting from the
ConfigOptions in the function itself. Then prior to execution we could update
all the functions that had option specific state. Something like:
```rust
// update config options...
// Update all registered functions:
for name in ctx.udf_names() {
let old_func = ctx.get_udf(&name);
if let Some(new_func) = new_func.with_config_options(options) {
ctx.register_udf(new_func)
}
}
```
This would make updating config options potentially slower (as now functions
would also need to be updated) but I think the change would be much more
localized
Another would be to use the existing
[`simplify`](https://docs.rs/datafusion/latest/datafusion/logical_expr/struct.ScalarUDF.html#method.simplify)
function and update [`SimplifyInfo`
](https://docs.rs/datafusion/latest/datafusion/logical_expr/simplify/trait.SimplifyInfo.html)
with the config options (likely much less disruptive)
--
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
