alamb commented on issue #10181: URL: https://github.com/apache/datafusion/issues/10181#issuecomment-2071950006
> Another way to tackle it could be to leave the concept of a GetIndexedField node at the parsing layer and pull it out of Expr (or deprecate). This would force the conversion to be done between the parse plan and the logical plan. I agree this would be clearest (basically remove `Expr::GetIndexedField` and always use a function. > I think we are talking about better API design of get_field right? I was actually thinking about an API for the usecase of "I created an `Expr `programatically and I want to convert it to a `PhyscalExpr` I can execute. We do this in InfluxDB IOx. I didn't realize that both LanceDB and Delta did the same thing Currently there is an example of how to do this in `expr_api.rs`: https://github.com/apache/datafusion/blob/711239fb13998fa5cfb1b1c865ac060613bad2c7/datafusion-examples/examples/expr_api.rs#L251-L252 Maybe it is time to "promote" that function to a real API in `datafusion-core` somewhere where it can be tested and better documented. > I think we can take reference from others. Duckdb has [struct_extract](https://duckdb.org/docs/sql/functions/nested#struct_extractstruct-entry) and [map_extract](https://duckdb.org/docs/sql/functions/nested#map_extractmap-key) Those are interesting functions -- now that we have the notion of function packages, adding better support for the Map datatype would be sweet. -- 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
