Subquery returns 0 rows-----HELP

Question

I need to understand something.
please follow my points:-
1-If we try to make a NOT IN condition, and one value is NULL, the main query return no result, because the NOT IN condition evaluates to FALSE "NULL" "UNKNOWN".
example:-
SELECT 'True' FROM employees
WHERE department_id NOT IN (10, 20, NULL);
this query returns no rows, simply because the condition is parsed like this
department_id != 10 AND department_id != 20 AND department_id != null
^^^I have no question regarding this point and it is quite obvious.
2-If the subquery returns 0 rows, then the value of the scalar subquery expression is NULL.
example:-
create table subq_null_test
num number(4),
val varchar2(7)
insert into subq_null_test
values (1,'one');
insert into subq_null_test
values (2, (select 'two' from dual where 2=1));
insert into subq_null_test
values (3, 'three');
commit;
and by
select * from subq_null_test;
we would see a NULL inserted as value for number 2
NUM VAL
1     one
2     (null)
3     three
so far so good, indeed the 0 row subquery returned NULL
^^^Also I CAN'T have a point here.
============================================
but lets look at these 3 queries
-------->FIRST
select department_id, last_name
from employees
where department_id not in (10,20,null)
/*no rows selected*/
--------->SECOND
select department_id, last_name
from employees
where department_id not in (10,20,(select 10 from dual where 2=1))
/*no rows selected*/
-------->THIRD
select department_id, last_name
from employees
where department_id not in (select 10 from dual where 2=1)
/*ROWS returned*/
my question is:-
WHY FIRST and SECOND queries behaved as expected, while the THIRD didn't ???
-I had a look at the execution plan, and it didn't helped me "am a beginner anyways"
-I know its something related to the process or parsing the conditions, but am totally unable to locate it...
Any help would be so much appreciated,
Thanks for all.
Ghazal.

Answer 1

Hi again
Yes; while I was writing my reply, you corrected it.Now it seems like you're making the same mistake again.I believe I had clarified it enough.
Once again, I was only talking about the situation where department_id is NULL.Of course "x IN y" can be TRUE, FALSE or UNKNOWN, depending of what x and y are. All I was saying is that "NULL IN y" can be FALSE (depending on y), even though "NULL = q" is always UNKNOWN, regardless of what q is, and I find that a little inconsistent.-now we are on the same side "I hope :)...jk"...well yea we are talking about the department_id "left-hand" operand is NULL.
-Regarding YOUR point, I can't agree with you Sir.
I see it pretty much consistent that when the left-hand operand is NULL,,,it is always UNKNOWN even if the right-side operand is a null.
I would even go further and say if there is a using of word "regardless", it wold be like this
if the left-hand operand is NULL the condition evaluates to UNKNOWN no matter what is in the right-hand operand REGARDLESS what condition we are using IN or NOT IN.
so
"x IN y" can be TRUE, FALSE or UNKNOWN, depending of what x and y are. All I was saying is that so far so good
"NULL IN y" can be FALSE (depending on y), even thoughNo, it is ALWAYS UNKNOWN 'you can call is FALSE'.
"NULL = q" is always UNKNOWN, regardless of what q is, and I find that a little inconsistent.I find it okay.
-"NULL = q" is always UNKNOWN regardless of what q is, is perfect and consistent indeed.
-"NULL in (q, p, d)" is always UNKNOWN.
-"NULL NOT in (q, p, d)" is always UNKNOWN.
I would again dare and go further and say
-whenever we have NULL on the left-hand operand
result of the condition is only 2 cases and can never be 3
1-UNKNOWN :- if we use "=, !=, IN, NOT IN, or anything may exists"
2-TRUE :- if we use "IS"
-this case of NULL as our left-hand operand can never have a FALSE case...
ORACLE does do this for us by her own, and thanks ORACLE for that...alot.
select 'BANG' from dual where null is null;
select 'BANG' from dual where (select department_id from employees where last_name = 'kokolala') in (10,20, null);
select 'BANG' from dual where (select department_id from employees where last_name = 'kokolala') is null ;This all is perfect, consistent, logical and cute.
Solomon Yakobson : Think about the dirrerence between empty list and list containing a null element.This is cool, correct. this is the actual solution to the matter of having a null in our right-hand operand "BY JUST IGNORING THE NULLS, and is the list have only nulls it becomes an empty list", but in our case we do NOT have an EMPTY list, we have a list with a NULL indeed.
-ORACLE just under the hood did us a favor of giving us an EMPTY list by ignoring the nulls using "LNNVL", which is doing no good..let him experience it, let him taste it, let him avoid it, him him him design it. and do not give me an inconsistent mechanism. it is good to sell that ORACLE is treating results as lists but that shouldn't intervene with our system-level language, am boooring guy, if its designed to work like this, no am sorry it should be stopped now.
My point is
-This theory is great regarding the matter when we are talking about dealing with our result as a LIST of elements, we would take in consideration our NULL values, which what SHOULD be implemented by the coder.
-BUT the issue of oracle implements "LNNVL" while parsing our codes INCASE and ONLY in the case of subquery as our right-hand operand, I am not buying it and i see it inconsistent.
They should implements it in all cases, or not at all "not even in one case as an exception", this is logic and it cant be divided or argued.Am still hoping someone have an explanation to the matter, I wouldn't like it at all to know that am 100% correct in my analysis of this case, because if I am I would like to see them changing it.
Edited by: Ghazal-OCA on Jan 8, 2013 7:04 AM
Edited by: Ghazal-OCA on Jan 8, 2013 7:10 AM
Edited by: Ghazal-OCA on Jan 8, 2013 7:19 AM
Edited by: Ghazal-OCA on Jan 8, 2013 7:20 AM
Edited by: Ghazal-OCA on Jan 8, 2013 7:23 AM