-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Unparse SubqueryAlias
without projections to SQL
#12896
Conversation
SubqueryAlias
without projections to SQL
After this changed, I found another issue about the anonymous subquery. SELECT
*
FROM
(
SELECT
customer.c_custkey AS custkey,
customer.c_name AS "name"
FROM
(
SELECT
customer.c_custkey,
customer.c_name
FROM
customer
)
) AS c This SQL is valid for DataFusion but it isn't valid for Postgres or DuckDB. The deepest-level subquery is anonymous, but its outer projection uses its column with the qualifier DataFusion
DuckDB
Postgres
For some SQL pushdown purposes, we are better off generating SQL with the common syntax. I'll file an issue and try to fix it. |
@@ -697,7 +739,7 @@ fn test_table_scan_pushdown() -> Result<()> { | |||
plan_to_sql(&table_scan_with_projection_alias)?; | |||
assert_eq!( | |||
format!("{}", table_scan_with_projection_alias), | |||
"SELECT ta.id, ta.age FROM t1 AS ta" | |||
"SELECT * FROM (SELECT ta.id, ta.age FROM t1 AS ta) AS ta" |
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.
That's not an improvement, right?
I am OK if this is necessary, but is there a different way to fix the original problem, without affecting 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.
Thanks @findepi. Sorry for replying so late 🙇
You're right. I shouldn't break the result of the table scan with any pushdown. I stopped projecting a wildcard if the SubqueryAlias
's child is a pushdown table scan.
.build()?; | ||
let table_scan_with_two_filter = plan_to_sql(&table_scan_with_two_filter)?; | ||
assert_eq!( | ||
format!("{}", table_scan_with_two_filter), |
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: format!
is unnecessary, just use table_scan_with_two_filter (or table_scan_with_two_filter.to_string()) in assert
(same in other places)
.project(vec![col("id")])? | ||
.alias("a")? | ||
.build()?; |
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.
should this be indented?
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's formatted by the cargo formatter. I think we can't control it 🤔
.project(vec![col("id")])? | ||
.alias("a")? | ||
.build()?; | ||
println!("{}", plan.display_indent()); |
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.
left over?
if scan.projection.is_some() | ||
|| !scan.filters.is_empty() | ||
|| scan.fetch.is_some() | ||
if let Some(unparsed_table_scan) = |
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.
Nice
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 @goldmedal and @findepi for the review
FYI @phillipleblanc and @sgrebnov |
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.
This PR makes sense to me, thanks!
LGTM 👍 |
Thanks @sgrebnov @findepi and @phillipleblanc for the review |
Thanks @alamb @sgrebnov @findepi @phillipleblanc ! |
* change pub function comment to doc * unparse subquery alias without projections * fix tests * rollback the empty line * rollback the empty line * exclude the table_scan with pushdown case * fmt and clippy * simplify the ast to string and remove unused debug code
* init (apache#12453) * Fix unparse table scan with the projection pushdown (apache#12534) * unparse the projection base on the source schema * refactor and enhance the test * Fix unparsing OFFSET (apache#12539) * Unparse Sort with pushdown limit to SQL string (apache#12873) * unparse Sort with push down limit * cargo fmt * set query limit directly * Unparse `SubqueryAlias` without projections to SQL (apache#12896) * change pub function comment to doc * unparse subquery alias without projections * fix tests * rollback the empty line * rollback the empty line * exclude the table_scan with pushdown case * fmt and clippy * simplify the ast to string and remove unused debug code * enhance unparsing plan with pushdown to avoid unnamed subquery (apache#13006) * Update --------- Co-authored-by: Lordworms <[email protected]> Co-authored-by: Jax Liu <[email protected]> Co-authored-by: Justus Flerlage <[email protected]>
Which issue does this PR close?
Closes #.
Rationale for this change
Consider the following SQL
The unoptimized plan is
However, after the
optimize_projections
rule, the top-level projection will be removed likeThe unparsing result would like
It's an invalid SQL because the column qualifier is the table name
customer
but it's in the aliasc
scope actually.What changes are included in this PR?
When unparsing a
SubqueryAlias
without any projections, we should create another scope for the alias likeAre these changes tested?
yes
Are there any user-facing changes?
The unparsing result is changed.