adriangb commented on PR #16791: URL: https://github.com/apache/datafusion/pull/16791#issuecomment-3078342870
> In particular I am not sure about the intended behavior when they are both present If you have an expression adapter you map the expression and the expression is now evaluated against the physical file schema. So there is no longer a need / point of having a SchemaAdapter. It will still be there but it becomes a no-op because it's adapting between identical schemas. I'm sorry I did not give more detail in the PR description. The idea is that there are one of 4 scenarios that users will fall into: 1. Custom SchemaAdapter, no custom PhysicalExprAdapter -> use SchemaAdapter / old code path 2. Default SchemaAdapter, no custom PhysicalExprAdapter -> use default PhysicalExprAdapter 3. Custom SchemaAdapter, custom PhysicalExprAdapter -> use the custom PhysicalExprAdapter (making the SchemaAdapter a no-op for predicate pushdown). 4. Default SchemaAdapter, custom PhysicalExprAdapter -> use custom PhysicalExprAdapter. This makes it completely backwards compatible: anyone using a custom SchemaAdapter has to make no code changes to continue using it. If they want to opt into the new mechanism they can either stop setting a custom SchemaAdapter or also set a custom PhysicalExprAdapter. A SchemaAdapter, custom or the default, is still used for projections. -- 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
