Detection of contradictions I found some old notes of mine from 2011 and I also re-read the excellent article 10 Cool SQL Optimisations That do not Depend on the Cost Model by @lukas-eder. So I thought I would take my notes for another spin. The scenario is quite simple Fiddle
create table emp ( 
    emp_no int not null primary key, 
    title varchar(10) not null, 
    salary int not null, 
        check (emp_no &gt; 0), 
        check (title in ('BOSS','WORK'))
);

insert into emp with recursive t (n) as (
    values (1) 
    union all 
    select n+1 from t where n+1 &lt; 1000
) select n, case when mod(n,10) = 0 then 'BOSS' else 'WORK' end, 
            case when mod(n,10) = 0 then 110 else 0 end + mod(n,90) 
from t;

Now, given the rules:
 (TITLE = BOSS) implies (SALARY &gt; 100)

and
 (TITLE = WORK) implies (SALARY &lt;= 100)

which can be implemented as:
-- (TITLE = BOSS) =&gt; (SALARY &gt; 100)
alter table emp add constraint cc1 
    CHECK ( (title &lt;&gt; 'BOSS' OR salary &gt; 100) );
-- (TITLE = WORK) =&gt; (SALARY &lt;= 100)
alter table emp add constraint cc2
    CHECK ( (title &lt;&gt; 'WORK' OR salary &lt;= 100) );

and the query:
select * 
from emp 
where title = 'BOSS' and salary &lt;= 100

can the DBMS spot the contradiction, and return an empty result set without even touching the data?
Let A = ( title = ’BOSS’ ), B = ( salary &gt; 100 )

select * from emp where (A ^ ~B)                    
select * from emp where (A ^ ~B) ^ (~A v B)           # by cc1 
select * from emp where (A ^ ~B ^ ~A) v (A ^ ~B ^ B)    
select * from emp where (FALSE ^ ~B) v (A ^ FALSE)      
select * from emp where (FALSE) v (FALSE)           
select * from emp where (FALSE)

I have tried Postgres 13 (see fiddle above)
Seq Scan on emp  (cost=0.00..26.50 rows=2 width=46) (actual time=0.134..0.134 rows=0 loops=1)
  Filter: ((salary &lt;= 100) AND ((title)::text = 'BOSS'::text))
  Rows Removed by Filter: 999
Planning Time: 0.312 ms
Execution Time: 0.149 ms

and Db2 11.5.4.0:
Optimized Statement:
-------------------
SELECT 
  Q1.EMP_NO AS &quot;EMP_NO&quot;,
  Q1.TITLE AS &quot;TITLE&quot;,
  Q1.SALARY AS &quot;SALARY&quot; 
FROM 
  DB2INST1.EMP AS Q1 
WHERE 
  (Q1.SALARY &lt;= 100) AND 
  (Q1.TITLE = 'BOSS')

Access Plan:
-----------
        Total Cost:             51.8267
        Query Degree:           1


      Rows 
     RETURN
     (   1)
      Cost 
       I/O 
       |
     90.2441 
     TBSCAN
     (   2)
     51.8267 
        4 
       |
       999 
 TABLE: DB2INST1
       EMP
       Q1

but both fail to do so. Any other DBMS that can spot the contradiction and act upon it? This is of course more of an amusement than a real-world problem, but still.
Edit: The constraint suggested by @federico-razzoli in his answer does not work either:
alter table emp add constraint cc1
    check ((title = 'BOSS' and salary &gt; 100) or 
           (title = 'WORK' AND salary &lt;= 100));

and the same query still causes table-access
 Rows 
 RETURN
 (   1)
  Cost 
   I/O 
   |
 90.2441 
 TBSCAN
 (   2)
 51.8267 
    4 
   |
   999 

TABLE: DB2INST1
EMP
Q1
Your question is great, but it skips one step. You are assuming that the query planner (or optimiser, depending which terminology you prefer) can keep into account all CHECKs, merging them.
So you have:
check (title in ('BOSS','WORK'))

And:
CHECK ( (title &lt;&gt; 'BOSS' OR salary &gt; 100) )
CHECK ( (title &lt;&gt; 'WORK' OR salary &lt;= 100) )

And you assume that the planner should be able to know that:
CHECK ((title = 'BOSS' and salary &gt; 100) or title = 'WORK' AND salary &lt;= 100)

This could be the case or not.
In general, the question to your answer depends on the technology you are using. MySQL and MariaDB don't take into account CHECKs. Some other technologies probably do. You'll have to test the technologies you are interested in.