Merge pull request #10 from Trivadis/feature/v4.2.1

Feature/v4.2.1

Author: PhilippSalvisberg

docs/tvdcc_report.html

@@ -51,15 +51,15 @@ Other command separators than semicolon (`;`) are not supported. This means that
 
 ## SQL Terminator
 
-Other SQL terminators than semicolon (`;`) are not supported. This means that the `set sqlterminator` command is ignored. Tailing whitespaces after a SQL terminator are not supported.
+Other SQL terminators than semicolon (`;`) are not supported. This means that the `set sqlterminator` command is ignored. Tailing whitespace after a SQL terminator are not supported.
 
 ## Line Continuation Character
 
-Tailing whitespaces after a line continuation character (`-`) are not supported.
+Tailing whitespace after a line continuation character (`-`) are not supported.
 
 ## Slash Command
 
-Tailing whitespaces after the slash command (`/`) are not supported.
+Tailing whitespace after the slash command (`/`) are not supported.
 
 ## Execute Command
 
@@ -298,7 +298,25 @@ Since db\* CODECOP and PL/SQL Analyzer do not include a PL/SQL unwrap utility, t
 
 ## SQL\*Plus Substitution Variables
 
-...
+Substitution variables are supported in the SQL\*Plus grammar. This means they work when used in in SQL\*Plus commands such as `connect`. 
+
+When a substitution variable is used in commands supported by the PL/SQL grammar (e.g. the `SELECT` statement), then it can be processed only when it can be replaced by a SQL expression or a condition. 
+
+Here's an example of a supported use of substitution variables:
+
+```sql
+select &&column_name 
+from emp
+where &&where_condition;
+```
+
+However, the following example is not supported supported and leads to a parse error:
+
+```sql
+select empno, ename 
+from emp
+&after_from_clause;
+```
 
 ## Supported Oracle Versions
 

docs/tvdcc_report.xlsx

@@ -45,19 +45,6 @@ You might find use cases where it feels ridiculous introducing a constant for a
 3. Write a own validator check, overriding the default behavior (see [this example](https://github.com/Trivadis/plsql-cop-validators/blob/main/src/main/java/com/trivadis/tvdcc/validators/OverrideTrivadisGuidelines.xtend#L67) ignoring calls of the logger framework)
 
 It's currently not possible to configure the behavior of this guideline check.
-
-### [G-1080](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/1-general/g-1080/): Avoid using the same expression on both sides of a relational comparison operator or a logical operator.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-2135](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/2-variables-and-types/1-general/g-2135/): Avoid assigning values to local variables that are not used by a subsequent statement.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-2145](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/2-variables-and-types/1-general/g-2145/): Never self-assign a variable.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-2410](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/2-variables-and-types/4-boolean-data-types/g-2410/): Try to use boolean data type for values with dual meaning.
 
 How are values with dual meaning identified?
@@ -91,14 +78,6 @@ end pkg;
 
 In this case for both `l_var` declarations a G-2410 violation should be thrown. Due to the simplified analysis scope three values are found for `l_var` and therefore no violation is thrown.
 
-### [G-2610](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/2-variables-and-types/6-cursor-variables/g-2610/): Never use self-defined weak ref cursor types.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-3115](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/1-general/g-3115/): Avoid self-assigning a column.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-3160](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/1-general/g-3160/): Avoid virtual columns to be visible.
 
 This check is not implemented. 
@@ -111,48 +90,12 @@ This check is not implemented.
 
 Requires `CREATE TABLE` and `ALTER TABLE` parser support or access to the Oracle Data Dicionary.
 
-### [G-3185](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/1-general/g-3185/): Never use ROWNUM at the same query level as ORDER BY.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-3195](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/1-general/g-3195/): Always use wildcards in a LIKE clause.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-3310](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/3-transaction-control/g-3310/): Never commit within a cursor loop.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-3320](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/3-dml-and-sql/3-transaction-control/g-3320/): Try to move transactions within a non-cursor loop into procedures.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-4250](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4250/): Avoid using identical conditions in different branches of the same IF or CASE statement.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-4260](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4260/): Avoid inverting boolean conditions with NOT.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-4270](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4270/): Avoid comparing boolean values to boolean literals.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-4325](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/4-control-structures/3-flow-control/g-4325/): Never reuse labels in inner scopes.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-5010](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/5-exception-handling/g-5010/): Try to use a error/logging framework for your application.
 
 This check is not implemented.
 
 Requires further definition regarding naming of the error/logging framework and its minimal use in PL/SQL code. However, could be implemented as a custom validator.
 
-### [G-5080](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/5-exception-handling/g-5080/): Always use FORMAT_ERROR_BACKTRACE when using FORMAT_ERROR_STACK or SQLERRM.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-7140](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/1-general/g-7140/): Always ensure that locally defined procedures or functions are referenced.
 
 This guideline is checked for CreateFunction, CreatePackageBody, CreateProcedure, CreateTrigger, CreateTypeBody and PlsqlUnit with a simplified scope. Variable declarations and usages are identified by name. The real PL/SQL scope is not honored. This might lead to false negatives. Here's an example:
@@ -207,32 +150,12 @@ end pkg;
 
 In the first procedure `p` the parameter `in_param` is not used. However, it is not reported due to the simplified analysis scope. Another procedure `p` has also a parameter `in_param` that has been used. 
 
-### [G-7125](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/1-general/g-7125/): Always use CREATE OR REPLACE instead of CREATE alone.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-7170](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/1-general/g-7170/): Avoid using an IN OUT parameter as IN or OUT only.
 
 This check is not implemented.
 
 We cannot determine the usage of an `in out` parameter in a reliable way, especially when other units are involved which are maintained in another file.
 
-### [G-7250](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/2-packages/g-7250/): Never use RETURN in package initialization block.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-7330](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/3-procedures/g-7330/): Always assign values to OUT parameters.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-7720](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/7-triggers/g-7720/): Never use multiple UPDATE OF in trigger event clause.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-7730](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/7-stored-objects/7-triggers/g-7730/): Avoid multiple DML events per trigger if primary key is assigned in trigger.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
 ### [G-8410](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/8-patterns/4-ensure-single-execution-at-a-time-of-a-program-unit/g-8410/): Always use application locks to ensure a program unit only running once at a given time.
 
 This check is not implemented.
@@ -244,15 +167,3 @@ Algorithms to detect wrong, missing and right usages of this pattern are virtual
 This check is not implemented.
 
 Algorithms to detect wrong, missing and right usages of this pattern are virtually impossible to implement without understanding the context of a certain PL/SQL code.
-
-### [G-9010](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/9-function-usage/g-9010/): Always use a format model in string to date/time conversion functions.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-9020](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/9-function-usage/g-9020/): Try to use a format model and NLS_NUMERIC_CHARACTERS in string to number conversion functions.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.
-
-### [G-9030](https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.0/4-language-usage/9-function-usage/g-9030/): Try to define a default value on conversion errors.
-
-This guideline was introduced in v4.0 and the check is not yet implemented.