-
Notifications
You must be signed in to change notification settings - Fork 617
Fix: JOIN should require ON condition #1552
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
Closed
Closed
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
a3244ea
on condition requirement for join
dmitriibugakov 5d1d6bb
Merge branch 'main' into fix-join-on-required
dmitriibugakov c10f0f7
minor changes
dmitriibugakov f19fd13
introduce verify_join_constraint
dmitriibugakov 62f8b0d
minor changes
dmitriibugakov 5727298
Merge branch 'main' into fix-join-on-required
dmitriibugakov cc1c2a4
add verify_join_operator to dialect
dmitriibugakov dc71f1a
Merge branch 'main' into fix-join-on-required
dmitriibugakov 40b38f6
minor changes
dmitriibugakov File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Ah so since the behavior seems to vary a bit across dialects, I'm thinking it could make sense after all if we let the parse continue to be permissive in syntax and downstream crates can perform the additional checks in the cases where specific combinations need to be enforced?
Uh oh!
There was an error while loading. Please reload this page.
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 understand your idea, and it makes sense. But the "issue" is based on the idea that the parser should restrict cases like “INNER JOIN” without an ON condition.
For me, as a developer, it would feel strange if I pick a parser, for example, the PostgreSQL dialect, and it allows “ANTI JOIN” without any error. This would mean I have to check all the statements again to find mistakes. It seems like a trade-off, and we need to decide which approach works best.
Or are you suggesting moving this specific implementation directly to
GenericDialect
?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.
Yeah it is indeed a tradeoff, the expectation currently is that downstream crates further validate the output of the parser against any dialect specific requirements/invariants, see note here for example
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.
@alamb, could you determine whether the issue outlined in #13486 is valid?
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.
In my opinion:
<left> JOIN <right>
without anON
clause then so should sqlparserI have not done the research to know if there are any dialects that support such syntax
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.
Currently, DataFusion processes
SELECT ... FROM l JOIN r
as aCROSS JOIN
for all dialects, including DuckDB, where anINNER JOIN
explicitly requires anON
clause.@Dandandan proposed addressing this issue in
sqlparser-rs
, which seems reasonable to me. However, after discussing it with @iffyio, I seeMy questions are:
datafusion
orsqlparser-rs
?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 don't have a strong opinion -- is it causing anyone problems? It seems like the ramification of allowing
JOIN
... asCROSS JOIN
's largest implication is that now DataFusion has some new dialect.If it isn't causing problems, my suggestion is do nothing until someone has a concrete usecase