-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update API for extension planning to include logical plan #643
Conversation
/// This errors when the planner knows how to plan the concrete implementation of `node` | ||
/// but errors while doing so, and `None` when the planner does not know how to plan the `node` | ||
/// and wants to delegate the planning to another [`ExtensionPlanner`]. | ||
/// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The challenge prior to this PR is if the extension node has any Expr
s to convert them into PhysicalExprs
requires access to the LogicalPlan
Furthermore, there was no way to call back into create_physical_expr
from the ExtensionPlanner
so I added that to the trait as well
Thank you for the review @houqp. Any thoughts @andygrove / @Dandandan / @jorgecarleitao ? Otherwise I would like to merge this in the next day or so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeap, clear for me. Great simplification and also some nice doc strings 👍
/// `input_schema`: the physical schema for evaluating `e` | ||
fn create_physical_expr( | ||
&self, | ||
e: &Expr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: why call it e
? I think expr
as variable name is more consistent with the whole codebase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree expr
is more consistent -- I think I was following the model of DefaultPhysicalPlanner::create_physical_expr
. I will change
input_schema: &Schema, | ||
ctx_state: &ExecutionContextState, | ||
) -> Result<Arc<dyn PhysicalExpr>> { | ||
self.create_physical_expr(e, input_dfschema, input_schema, ctx_state) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From here it looks like infinite recursion, but I might be wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It somehow knows to call DefaultPhysicalPlanner::create_physical_expr
-- I will make this clear
3b3112d
to
d61280a
Compare
Which issue does this PR close?
Closes #642
Rationale for this change
With the introduction of qualified identifiers in #55 I am having trouble creating plans with user defined nodes because the extension traits don't have sufficient information about the logical plan to create the correct
PhysicalExpr
s.#642 describes in more detail what is going on
What changes are included in this PR?
PhysicalPlanner::create_physical_expr
to the planer traitExtensionPlanner::plan_extension
to include a reference to the planner as well as the logical inputsAre there any user-facing changes?
Yes: Extension API and PhysicalPlanner interfaces have changed