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


*Noteworthy*

This rule raises issues only when a *Data Dictionary* is provided during the analysis. See https://docs.sonarqube.org/latest/analysis/languages/plsql/

=== Noncompliant code example

[source,sql]
----
CREATE TABLE product
(id INT,
  name VARCHAR(6) NOT NULL,
  mfg_name VARCHAR(6),
  mfg_id INT
  ...

SELECT name, price
FROM product
WHERE name is not null -- Noncompliant; always true. This column is NOT NULL
  AND mfg_name = 'Too long name' -- Noncompliant; always false. This column can contain only 6 characters
----

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

* Based on the definition of "ccc", this condition is always ["TRUE"|"FALSE"].
* Based on the constraints on "ccc", this condition is always ["TRUE"|"FALSE"].
* Change this condition so that it does not always evaluate to ["TRUE"|"FALSE"].


=== Highlighting

problem condition


'''
== Comments And Links
(visible only on this page)

=== relates to: S2583

=== relates to: S3633

=== on 17 Jun 2016, 15:03:20 Ann Campbell wrote:
from \https://www.researchgate.net/publication/222432151_Semantic_errors_in_SQL_queries_A_quite_complete_list:


Error 27: Uncorrelated EXISTS-subqueries.If an EXISTS-subquery makes no reference to a tuple variable from theouter query, is is either globally true or globally false. This is a very unusualbehaviour. Actually, uncorrelated EXISTS-subqueries are simply missing joinconditions (possibly for anti-joins).


Not sure if we want to handle this here or in RSPEC-3647


endif::env-github,rspecator-view[]