-
-
Notifications
You must be signed in to change notification settings - Fork 873
ST06 - Fix union of CTE/Subquery #6298
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
ST06 - Fix union of CTE/Subquery #6298
Conversation
Add failing test cases, no fix yet.
Not sure if CI will be 100% green, but this looks fairly good in my local environment. |
Coverage Results ✅
|
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. I think there's an optional way of making this even better but I love the approach.
src/sqlfluff/rules/structure/ST06.py
Outdated
maybe_with_compound_statement = seg.get_parent() | ||
if maybe_with_compound_statement is None: | ||
break | ||
with_compound_statement, _ = maybe_with_compound_statement |
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.
The coverage checks are failing because of this line, but it's very unlikely that would ever get used. If you add a comment here saying that clause is mostly a safety measure, then I think it's also ok to mark it as # pragma: no cover
.
It would only be None
if a fix has modified it in some way and we haven't yet re-populated the parent. Even in that scenario it's very unlikely.
src/sqlfluff/rules/structure/ST06.py
Outdated
): | ||
return None | ||
|
||
# CTE is order-sensitive only if CTE is referenced in set expression |
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 a small thing, which you can choose whether to address: The order is only sensitive if a wildcard (*) is used. In the case of a set expression where all the columns are re-specified, it would be ok to reorder them here - it's only when the set expression uses a *
that it becomes a problem.
For bonus points, taking that into account would be awesome.
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 great! Thanks for the edits 🚀
Add failing test cases, no fix yet.
Brief summary of the change made
Fixes #5956
Are there any other side effects of this change that we should be aware of?
Pull Request checklist
Please confirm you have completed any of the necessary steps below.
Included test cases to demonstrate any code changes, which may be one or more of the following:
.yml
rule test cases intest/fixtures/rules/std_rule_cases
..sql
/.yml
parser test cases intest/fixtures/dialects
(note YML files can be auto generated withtox -e generate-fixture-yml
).test/fixtures/linter/autofix
.Added appropriate documentation for the change.
Created GitHub issues for any relevant followup/future enhancements if appropriate.