adriangb commented on PR #20901: URL: https://github.com/apache/datafusion/pull/20901#issuecomment-4130289020
> A lot of the reservations I have with the way this PR and #20416 are proposing to extend dynamic filters in functionality arise from the fact that the blast radius of these contributions is pretty big, as they need to rely on extending very central pillars of DataFusion like `PhysicalExpr` for getting the job done, when the actual functionality is scoped to just dynamic filters. > > IMHO, If we had a way of contributing functionality to dynamic filters without necessarily touching the very core of DataFusion, the flow of these contributions would be much smoother, and I could imagine how representing dynamic filters, not as `PhysicalExpr` implementations, but as first class `DynamicFilter` structs, has good chances of delivering such vision. Makes sense. I wonder what the alternative looks like though? If we make them their own thing, do we need to duplicate or break all of the APIs (filter pushdown, remapping child column physical indices... basically anything that touches `PhysicalExpr`)? -- 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]
