Conversation
d213758 to
a9dfd29
Compare
|
cc @Jefffrey I wonder if you have time to review this PR? |
Jefffrey
left a comment
There was a problem hiding this comment.
thanks for this, left a few nitpicks/comments
| let plan = LogicalPlanBuilder::from(sub_plan.clone()) | ||
| .project(projection_exprs)? | ||
| .alias(table_name)?; | ||
| .alias(table_name.to_string())?; |
There was a problem hiding this comment.
will subquery_alias need similar treatment to have an OwnedTableReference instead of String? or String itself should be just fine?
There was a problem hiding this comment.
I think it is actually important that the subquery alias is a non parsed string here (otherwise tests fail).
This rewrite is effectively inlining the view defition as a named subquery (that doesn't make sense to be in a schema):
...
FROM <view definition> as "table_name"I will add a comment here.
| pub fn from_qualified<'a>( | ||
| qualifier: impl Into<TableReference<'a>>, |
There was a problem hiding this comment.
im curious about why explicit lifetime is needed here?
There was a problem hiding this comment.
Basically because the compiler told me to do so 😆
But seriously, I think the reason is that impl doesn't support anonymous lifetimes -- I would have to change this to use the explicit generic syntax
Here is what happens if I remove <'a>:
--> datafusion/common/src/dfschema.rs:113:45
|
113 | qualifier: impl Into<TableReference<'_>>,
| ^^ expected named lifetime parameter
|
help: consider introducing a named lifetime parameter
|
112 ~ pub fn try_from_qualified_schema<'a>(
113 ~ qualifier: impl Into<TableReference<'a>>,
|
| } | ||
|
|
||
| fn test_plan() -> LogicalPlan { | ||
| let table_ref: Option<TableReference<'_>> = None; |
There was a problem hiding this comment.
use TableReference::none() that you introduced?
| let table_source = table_source(table_schema); | ||
| let name = name | ||
| .map(|n| n.into()) | ||
| .unwrap_or_else(|| OwnedTableReference::bare(UNNAMED_TABLE)) |
There was a problem hiding this comment.
maybe TableReference::bare(UNNAMED_TABLE) instead since next line is to_owned_reference() anyway?
Co-authored-by: Jeffrey <22608443+Jefffrey@users.noreply.github.com>
…datafusion into alamb/owned_table_reference
| pub fn from_qualified<'a>( | ||
| qualifier: impl Into<TableReference<'a>>, |
There was a problem hiding this comment.
Basically because the compiler told me to do so 😆
But seriously, I think the reason is that impl doesn't support anonymous lifetimes -- I would have to change this to use the explicit generic syntax
Here is what happens if I remove <'a>:
--> datafusion/common/src/dfschema.rs:113:45
|
113 | qualifier: impl Into<TableReference<'_>>,
| ^^ expected named lifetime parameter
|
help: consider introducing a named lifetime parameter
|
112 ~ pub fn try_from_qualified_schema<'a>(
113 ~ qualifier: impl Into<TableReference<'a>>,
|
| } | ||
|
|
||
| fn test_plan() -> LogicalPlan { | ||
| let table_ref: Option<TableReference<'_>> = None; |
| let plan = LogicalPlanBuilder::from(sub_plan.clone()) | ||
| .project(projection_exprs)? | ||
| .alias(table_name)?; | ||
| .alias(table_name.to_string())?; |
There was a problem hiding this comment.
I think it is actually important that the subquery alias is a non parsed string here (otherwise tests fail).
This rewrite is effectively inlining the view defition as a named subquery (that doesn't make sense to be in a schema):
...
FROM <view definition> as "table_name"I will add a comment here.
|
Thanks again for the review @Jefffrey -- since this is blocking me downstream (in IOx, where we are basically playing the role of early adopters / testers) I plan to merge this PR in later today. |
Which issue does this PR close?
Closes #5522
Rationale for this change
After #5343 some APIs take a String and parse it like a table reference (aka apply sql normalization rules to it)
What changes are included in this PR?
TBD
Are these changes tested?
Yes, both existing tests as well as new unit tests
Are there any user-facing changes?
Theoretically yes, but he existing
LogicalPlanBuilder::scan("tablename", ...)will continue to work so no major API work will be needed