Configurable illegal constructs

Inizia leggendo ASTMapping.fs per comprendere i pattern di visitor SQL esistenti, quindi esamina la documentazione sulla configurazione di rzsql.json. Definisci l'ambito della configurazione del linter per i costrutti elencati, inclusi i confronti con NULL e le clausole WHERE mancanti. Il lavoro è completato quando il progetto può selezionare i costrutti consentiti e vietati e segnalare le violazioni configurate.

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.

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.

    "constructs": {
         "allowed": ["MissingWhereClause"],
         "banned": ["NullComparison", "UnsafeInjectRawSQL"]
    }  

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".

    "linters": {
         "blacklist": ["NoMissingWhereClause"],
         "whitelist": ["NullComparisonAlwaysFalse", "NoUnsafeInjectRawSQL"]
    }