Skip to content

Commit

Permalink
Address comments
Browse files Browse the repository at this point in the history
  • Loading branch information
sebastien-marichal committed Nov 27, 2024
1 parent b6711c4 commit df82395
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 5 deletions.
3 changes: 0 additions & 3 deletions rules/S3618/plsql/rule.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -40,9 +40,6 @@ VALUES
[source,sql,diff-id=1,diff-type=compliant]
----
INSERT INTO MY_TABLE -- Compliant; N3 has a default value
(
N1
)
(
N1,
N2
Expand Down
2 changes: 1 addition & 1 deletion rules/S3641/how.adoc
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
== How to fix it

Use `NOT EXISTS` or `IS NOT NULL` instead od `NOT IN` when the subquery may return `NULL` values.
Use `NOT EXISTS` or `IS NOT NULL` instead of `NOT IN` when the subquery may return `NULL` values.

=== Code examples

Expand Down
4 changes: 3 additions & 1 deletion rules/S3651/plsql/rule.adoc
Original file line number Diff line number Diff line change
@@ -1,11 +1,13 @@
== Why is this an issue?

`WHERE` clause conditions that reinforce or contradict the definitions of their columns are useless; they are always either unconditionally true or unconditionally false. For instance, there's no point in including `AND column IS NOT NULL` if the column is defined as non-null.
Conditions in the `WHERE` clause that either reinforce or contradict the definitions of their columns are redundant, as they are always either unconditionally true or unconditionally false. For example, including `AND column IS NOT NULL` is unnecessary if the column is already defined as non-null.

include::../../../shared_content/plsql/data_dictionary.adoc[]

== How to fix it

Ensure that the conditions in the `WHERE` clause are not always true or false.

=== Code examples

Given the following table:
Expand Down

0 comments on commit df82395

Please sign in to comment.