G-1920
🆓Avoid syntax errors.
Reason
A syntax error means that dbLinter cannot parse the code successfully. If the code compiles successfully, this is either a limitation or a bug in the underlying parser. In any case, the resulting parse tree is incomplete. Using it to check the code could lead to false positives. Therefore we suppress reporting issues for code with syntax errors by default.
Try to find a solution that does not produce a syntax error. This will ensure that other problems in the file are not hidden.
Examples
Non-Compliant Example
with pro as (select 42) select * from pro;
Issues
| Line | Column | Message |
|---|---|---|
| 3 | 8 | no viable alternative at input 'with pro as (select 42) select *' |
The code is valid SQL. However, the IslandSQL scope lexer is identifying the second line as a PROMPT statement and putting it on the hidden channel. In other words the parser does not see the second line. It tries to parse with select * from pro; which results in a syntax error.
Compliant Solution - ★★★☆☆
with "PRO" as (select 42) select * from pro;
Now the second line is no longer identified as a PROMPT statement. However, using a quoted identifier violates G-2180 (Never use quoted identifiers).
Compliant Solution - ★★★★☆
with pro as (select 42) select * from pro;
This is another alternative that ensures that the second line is no longer identified as a PROMPT statement. It is better than the previous solution because it doesn't violate any other rule. However, there is a risk that reformatting the code will bring back the original syntax error.
Compliant Solution - ★★★★★
with fourty_two as (select 42) select * from fourty_two;
Choosing a non-conflicting alias is the most robust solution. You can format the code any way you like without risking bringing back the original syntax error, and it does not violate any other rule.
References
- same as plsql:PlSql.ParsingError
- same as Trivadis E-0002
E-0002 is not explicitly documented as a guideline. However, it is used within the db* CODECOP product suite.