L042 loop limit on fixes reached when CTE itself contains a subquery
See original GitHub issueSearch before asking
- I searched the issues and found no similar issues.
What Happened
While running sqlfluff fix --dialect snowflake
on a sql file, I get
==== finding fixable violations ====
WARNING Loop limit on fixes reached [10].
==== no fixable linting violations found ====
All Finished 📜 🎉!
[22 unfixable linting violations found]
INSERT OVERWRITE INTO dwh.test_table
WITH cte1 AS (
SELECT *
FROM (SELECT
*,
ROW_NUMBER() OVER (PARTITION BY r ORDER BY updated_at DESC) AS latest
FROM mongo.temp
WHERE latest = 1
))
SELECT * FROM cte1 WHERE 1=1;
All of the 22 violations are a mix of L002, L003 and L004.
Expected Behaviour
sqlfluff
should be able to fix the violations
Observed Behaviour
Even if I try to fix the violations manually, it still shows the same error.
How to reproduce
I will try to generate a sql file that will be able to reproduce the issue
Dialect
Snowflake
Version
1.1.0
Configuration
# https://docs.sqlfluff.com/en/stable/rules.html
[sqlfluff]
exclude_rules = L029, L031, L034
[sqlfluff:indentation]
indented_joins = true
indented_using_on = true
[sqlfluff:rules:L002]
tab_space_size = 4
[sqlfluff:rules:L003]
hanging_indents = true
indent_unit = tab
tab_space_size = 4
[sqlfluff:rules:L004]
indent_unit = tab
tab_space_size = 4
[sqlfluff:rules:L010]
capitalisation_policy = upper
[sqlfluff:rules:L011]
aliasing = explicit
[sqlfluff:rules:L012]
aliasing = explicit
[sqlfluff:rules:L014]
extended_capitalisation_policy = lower
[sqlfluff:rules:L016]
ignore_comment_clauses = true
ignore_comment_lines = true
indent_unit = tab
tab_space_size = 4
[sqlfluff:rules:L019]
comma_style = trailing
[sqlfluff:rules:L022]
comma_style = trailing
[sqlfluff:rules:L028]
single_table_references = unqualified
[sqlfluff:rules:L030]
extended_capitalisation_policy = upper
[sqlfluff:rules:L040]
capitalisation_policy = upper
[sqlfluff:rules:L042]
forbid_subquery_in = both
[sqlfluff:rules:L054]
group_by_and_order_by_style = explicit
[sqlfluff:rules:L063]
extended_capitalisation_policy = upper
[sqlfluff:rules:L066]
min_alias_length = 3
max_alias_length = 15
[sqlfluff:templater:jinja:context]
params = {"DB": "DEMO"}
Are you willing to work on and submit a PR to address the issue?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project’s Code of Conduct
Issue Analytics
- State:
- Created a year ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Working with CTEs (Common Table Expressions)
A CTE (common table expression) is a named subquery defined in a WITH clause. ... A recursive CTE can join a table to...
Read more >Subquery vs. CTE: A SQL Primer - LearnSQL.com
SQL subqueries and CTEs seem similar, but even pros may not know all ... In each step, the query expands itself and changes...
Read more >Is there a performance difference between CTE , Sub-Query ...
I've recently been told that in terms of efficiency, temporary tables are a good first choice as they have an associated histogram i.e....
Read more >Why is my CTE so slow? - SQLShack
Have you ever written up a complex query using Common Table Expressions (CTEs) only to be disappointed by the performance?
Read more >WITH clause - Amazon Redshift - AWS Documentation
A recursive common table expression (CTE) is a CTE that references itself. ... In turn, the WHERE clause of the main query block...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
PR #3697 avoids the looping behavior. Lint issues are still flagged, but the rule does not attempt to fix it if it would cause a loop. We should still try and figure out why this is happening, so the rule can actually autofix the code, but that’s lower priority (and probably a separate PR).
Looks like this simpler example also produces it:
This only has one linting failure:
So basically L042 gets in a recursive loop when trying to fix CTEs that also break L042.
For now you can manually fix that (or exclude L042 for this query) to prevent the error.