SQL> SELECT ‘yes’ AS hehe FROM DUAL WHERE ” IS NULL;

HEHE
——————————–
yes

SQL>

As far as the example is concerned:

SELECT * FROM objects WHERE id NOT IN (SELECT object_id FROM secondary)

Why not write it as

SELECT * FROM objects WHERE id NOT IN (SELECT object_id FROM secondary WHERE object_id IS NOT NULL)

This avoids the problem, doesn’t it?

ad. 1: perhaps it is badly named, but there is nowhere claim that “+” should work the same as sum() which is aggregate. the moment you know that aggregates ignore nulls, there are no surprises.

ad. 2: no, it is not false. sql logic is based on not 2, but 3 values. something that isn’t true doesn’t have to be false. “where” need condition that evaluates to “true”. anything else is rejected. it doesn’t mean in any way that null = false, as this: “select 1 where not null” still doesn’t return any rows, and if it was the case you described – it would.

ad. 3: basically the same thing as with “where”, but checks are checked for *false* value. again. something that isn’t true doesn’t mean it’s false.

and again – 3 value logic works quite well when you’ll assume null to be “unknown”.

where – requires “true”, not something that we don’t know or something that we know is false.
check – it stops entering “false” values, but if it is not definitely false – it can be inserted. it might be “true”. it might be simply “unknown”. but it’s not “false”.

1. null as no value:

If you select the SUM of a table (or group or subselect) and there are no input tuples, it returns NULL. Clearly this is not unknown, because your source data contains no NULLs. If you know everything, how can the results of a query be unknown?

Also, with outer join, how can outer join produce “unknown” when there are no NULLs in your source data?

And as a final observation: if you SUM() a column with NULLs in it in addition to integers, the NULLs will be ignored, and it will produce a value (if NULLs are unknown, clearly it’s wrong to count them as zero). Thus, as I point out in my slides, SUM() of NULL and 1 is 1, but NULL + 1 is NULL.

2. NULL is clearly false in a WHERE clause:
SELECT 1;
SELECT 1 WHERE NULL; — same as “WHERE FALSE”

3. Add a “CHECK (NULL)” as a constraint. It will not reject anything, and is therefore equivalent to “CHECK (TRUE)”.

btw. i swear that wordpress once had the ability to edit comments, but it seems to be gone now.

If you could write examples on:
1. null as no value in case of outer join
2. null as false in where
3. null as true in constraints

I’m not arguing with your points – I would just like to see some justification for the points, because I can’t find any examples in my memory, and the only example left (no value in aggregates) is easily explainable by the fact that aggregates should skip null values.

As far as I recall, this “skip nulls in aggregates” comes from standard, but I might be wrong.

That’s not true. See my slides from this talk:

http://www.pgcon.org/2008/schedule/events/83.en.html

Sometimes NULL is treated like unknown (operators, functions, [NOT] IN), sometimes it’s treated like no value at all (aggregates and outer joins), sometimes it’s treated like false (WHERE clause), and sometimes it’s treated like true (constraints).

These inconsistencies can lead to very unintuitive results.

In all recent versions of Oracle (maybe every version) NULL becomes ” when Oracle thinks it needs to and ” becomes NULL always.

In Oracle:

select count(*) from dual where ” is null;

…returns 1 (dual is an Oracle-standard one row table)

select ‘abc’||null||’123′ from dual;

…returns ‘abc123′

select length(”) from dual;

…returns NULL

If Oracle followed the standard, the first query would return 0 no matter how many rows dual had, the second would return null, and the third would return 0. These non-standard behaviors are so well entrenched in the Oracle world that I doubt they will change anytime soon.

pagila=# SELECT * FROM objects WHERE exists (SELECT object_id FROM secondary where object_id = id);
id
—-
2
(1 row)

pagila=# SELECT * FROM objects WHERE not exists (SELECT object_id FROM secondary where object_id = id);
id
—-
1
3
(2 rows)

SELECT name FROM tbl WHERE value > ALL (SELECT value FROM tbl WHERE fltr=’Blah’);

SELECT name FROM tbl WHERE value > (SELECT max(value) from tbl WHERE fltr=’Blah’);

You did good write-up, and I’m not criticizing you, I’m just saying that there is no bug, there is no issue. This works as expected.

And if PG changed how this works, THAT would be a problem.

Stated differently, if something is NULL and something has a value (string, int, numeric, etc…) they are clearly not equal by no stretch of any imagination or conjecture so they should be considered NOT IN-cluded in the comparisons.