alamb commented on issue #6339: URL: https://github.com/apache/arrow-datafusion/issues/6339#issuecomment-1547666620
> Aren't these arguments mostly applicable to the read side as well? Yes, basically, and if I could change it now I would change it not to return an `ExecutionPlan` somehow. > I am worried that we may prematurely commit to a design without enough clarity in all possible implications and usage patterns. > I think this kind of a design question should be decided after we have some more concrete cases (i.e. more write execs like we have read execs now) and thus have enough data points to analyze various use cases. Only then we can perform a more serious pros/cons analysis. In this case, maybe the decision will be to refactor the read side as well, or maybe we'll see that doing this is not the right thing to do even for the write side. I think this is a good point (and there is some evidence for us not really knowing what the API should be in the discussions above with @tustvold like https://github.com/apache/arrow-datafusion/issues/6339#issuecomment-1545962773) . I think we can leave the `TableProvider` API in terms of `ExecutionPlan` and simply refactor the implementations to require less boiler plate code. Let me see spend some more time with https://github.com/apache/arrow-datafusion/pull/6347 refining the idea -- 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]
