You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some constructs that are legal SQL but are almost certainly mistakes if found in a static, handwritten query.
The primary examples that come to mind are:
NULL comparison is always false.
select*from Foo where Bar =null-- `expr = null` is always false, should probably be `Bar IS null`
UPDATE/DELETE without WHERE clause is usually a mistake
update User set Email = @newEmail
-- uhhh... you probably forgot to put `where Id = @userId`
Idea
RZSQL should have some "linters" that implement a visitor for SQL statements and expressions (like ASTMapping.fs but without any output). There should be a separate linter class for each type of bogus construct we can think of.
In rzsql.json there could be an option like so, to determine which linters will run on the SQL statements in the project.
This would let you override the linters enabled/disabled. Having both a whitelist and blacklist would let us pick a reasonable set of default linters that wouldn't be overly strict or overly lenient.
Linters would be named after the construct they throw an error upon recognizing. This way the constructs configuration setting reads like a list of what kinds of SQL are allowed and banned in your project. The goal here is to avoid the double-negative confusion that would result from something like the below, where we are effectively saying "we DON'T want the linter that checks for NOT having a where clause, because we DO want those statements in our SQL code".
Motivation
There are some constructs that are legal SQL but are almost certainly mistakes if found in a static, handwritten query.
The primary examples that come to mind are:
NULL comparison is always false.
UPDATE/DELETE without WHERE clause is usually a mistake
Idea
RZSQL should have some "linters" that implement a visitor for SQL statements and expressions (like ASTMapping.fs but without any output). There should be a separate linter class for each type of bogus construct we can think of.
In rzsql.json there could be an option like so, to determine which linters will run on the SQL statements in the project.
This would let you override the linters enabled/disabled. Having both a whitelist and blacklist would let us pick a reasonable set of default linters that wouldn't be overly strict or overly lenient.
Linters would be named after the construct they throw an error upon recognizing. This way the
constructs
configuration setting reads like a list of what kinds of SQL are allowed and banned in your project. The goal here is to avoid the double-negative confusion that would result from something like the below, where we are effectively saying "we DON'T want the linter that checks for NOT having a where clause, because we DO want those statements in our SQL code".The text was updated successfully, but these errors were encountered: