Is your feature request related to a problem or challenge? Please describe what you are trying to do.
There are various reasons why I would like LogicalPlanBuilder to move to the same crate as LogicalPlan:
The reason we can't just move LogicalPlanBuilder in its current state is that the scan_* methods depend on the datasource module from the core crate (which in turn depend on the physical plan). Given that these methods are mostly just called from the execution context, I propose that we move the logic fully into the execution context and then just call a version of LogicalPlanBuilder::scan that accepts a TableSource instead.
Describe the solution you'd like
See above.
Describe alternatives you've considered
None
Additional context
None
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
There are various reasons why I would like
LogicalPlanBuilderto move to the same crate asLogicalPlan:LogicalPlanandLogicalPlanBuilderto be in the same crate. It would help with documentation and testing and also prevent us from adding accidental dependencies on the physical plan in the future.The reason we can't just move
LogicalPlanBuilderin its current state is that thescan_*methods depend on thedatasourcemodule from the core crate (which in turn depend on the physical plan). Given that these methods are mostly just called from the execution context, I propose that we move the logic fully into the execution context and then just call a version ofLogicalPlanBuilder::scanthat accepts aTableSourceinstead.Describe the solution you'd like
See above.
Describe alternatives you've considered
None
Additional context
None