-
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
Implement Unparser for UNION ALL
#10603
Conversation
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.
Looks like a nice improvement to me. Thank you @phillipleblanc
@@ -347,8 +373,33 @@ impl Unparser<'_> { | |||
|
|||
Ok(()) | |||
} | |||
LogicalPlan::Union(_union) => { | |||
not_impl_err!("Unsupported operator: {plan:?}") | |||
LogicalPlan::Union(union) => { |
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 double checked that Union is UNION ALL https://docs.rs/datafusion/latest/datafusion/logical_expr/struct.Union.html
@@ -4641,6 +4641,14 @@ fn roundtrip_statement() -> Result<()> { | |||
group by "Last Name", p.id | |||
having count_first_name>5 and count_first_name<10 | |||
order by count_first_name, "Last Name""#, | |||
r#"SELECT j1_string as string FROM j1 |
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.
Perhaps we should also add a test (as a follow on PR) for UNION
(not UNION ALL
)
Which issue does this PR close?
It doesn't close this issue, but is part of the work for #9494
Rationale for this change
Adds support for turning LogicalPlans that have
Union
LogicalPlans (without distinct, so onlyUNION ALL
, notUNION
) into SQL strings.It should be relatively easy now to support bare
UNION
by first inspecting theDistinct
node - but I ran out of time on this PR.What changes are included in this PR?
Splits
select_to_sql
into two parts:select_to_sql_statement
andselect_to_sql_expr
. LIMIT and ORDER BY are only valid in a statement context, whereas all other plans can appear in a SELECT expression. This allows the parsing for UNION ALL to turn each of its inputs into a SELECT expression, and still respect the LIMIT/ORDER BY at the statement level.Are these changes tested?
Yes, added two tests to the
roundtrip_sql
integration test.Are there any user-facing changes?
This expands the valid plans that can be unparsed back to SQL strings, and is backwards compatible.