-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Move sql_compound_identifier_to_expr
to ExprPlanner
#11487
Conversation
@@ -135,16 +138,17 @@ impl<'a, S: ContextProvider> SqlToRel<'a, S> { | |||
let nested_name = nested_names[0].to_string(); | |||
|
|||
let col = Expr::Column(Column::from((qualifier, field))); | |||
if let Some(udf) = | |||
self.context_provider.get_function_meta("get_field") |
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 wonder could we plan the whole compound identifier, the benefit of plan_*
function is able to customize the operator (in this case is compound identifier i.e. a.b.c
) and expressions we get.
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.
Ideally i wanted to do that same, but this function uses IdentNormalizer
field of SqlToRel
struct. I am just thinking a way around & wanted to discuss the same here.
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.
We can use the result of self.normalizer.normalize()
as the planner arguments, similar to the spirit of others function that we take the result of sql_expr_to_logical_expr
as the planner arguments
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.
How about this revision ? Do you think we aligned here ? There is still more work to do.
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.
fn sql_compound_identifier_to_expr
does many things, handles the logic for variable, compund indentifier & compund indentifier in outer query. In this change we are only supporting compund indentifier & not adding support compund indentifier in outer query.
GetField
to ExprPlanner
sql_compound_identifier_to_expr
to ExprPlanner
Weired that checks are failing, same are passing for me locally. Need to investigate |
@jayzhan211 I apologize for any confusion caused by submitting multiple reviews. I was mistaken in believing I had the latest changes from the |
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.
Thank you @dharanad and @jayzhan211 -- I think this PR is looking close. I had a few suggestions but I think it is quite close
It will be great to finally complete the user defined extension planner epic 🙏
# Conflicts: # datafusion/expr/src/planner.rs
@@ -115,6 +117,139 @@ fn concat_ws_literals() -> Result<()> { | |||
Ok(()) | |||
} | |||
|
|||
#[test] | |||
fn anti_join_with_join_filter() -> Result<()> { |
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.
why are these tests moved? Does that mean we can't plan SQL with identifiers like test.col_int32
without an Expr planner?
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.
For the earlier implementation, I also moved plannig of basic SQL like column references to expr planner, we had to move these test cases from optimizer
crate to core
to avoid optimizer
crate dependecy on functions
.
Since we have moved that out of planner, ideally i should moved the testcases back. My bad, i missed them. Thanks for catching this. I have fixed this.
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.
Thanks @dharanad -- other than the one question about why the tests were moved, I think this PR is looking good to me.
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.
👍
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.
Thanks @dharanad and @jayzhan211 -- I think this one looks really nice.
* move get_field to expr planner * formatting * formatting * documentation * refactor * documentation & fix's * move optimizer tests to core * fix breaking tc's * cleanup * fix examples * formatting * rm datafusion-functions from optimizer * update compound identifier * update planner * update planner * formatting * reverting optimizer tests * formatting
* move get_field to expr planner * formatting * formatting * documentation * refactor * documentation & fix's * move optimizer tests to core * fix breaking tc's * cleanup * fix examples * formatting * rm datafusion-functions from optimizer * update compound identifier * update planner * update planner * formatting * reverting optimizer tests * formatting
Which issue does this PR close?
Part of #11473
Rationale for this change
Part of #11207 moving the planning of
compound_identifier
toExprPlanner
, this change does not include planning forcompound_identifier
in outer queryWhat changes are included in this PR?
optimizer
crate dependent onfunctions
todatafusion/core/tests/optimizer_integration.rs
.MockContextProvider
to fix the breaking testcases.Are these changes tested?
Existing test cases
Are there any user-facing changes?
No