  > WHERE column = NULL and then query WHERE column <> NULL

With respect, your statement seems to indicate that you simply haven’t heard of or don’t understand the three-valued-logic semantics behind SQL.

NULL means what it means and is conceptually foundational to SQL. Comparing it to anything returns UNKNOWN, the “third value” besides true and false. And WHERE needs a TRUE predicate. So your implied fault that they “have no problem“ really is just a matter of you not understanding the tool you are complaining about.

To match against the NULLness of a value you must use special purpose operators. In this case

   WHERE column IS NULL OR column IS NOT NULL

▲ mrkeen 2 hours ago | parent [-]

Hi apologist. How was the woodwork? Your exact comment was why I wrote mine.

  You could write predicates over non-existent columns:

  root=> SELECT * FROM t
         WHERE definitely_not_a_column = 4;

Cool, definitely_not_a_column doesn't exist, so therefore that whole WHERE clause doesn't exist either, so the real query is SELECT FROM t.
SELECT * FROM t WHERE 4 = 5; a | b ---+---- 5 | 6 (1 row)
We're comparing 4 and 5. Precedent?
System.out.println(((Integer)4).compareTo((Integer)5)); > -1
What happens when you treat -1 as a bool? The following languages agree that -1 is true: C, C++, JS, Python, PHP, Ruby, Perl, Lua, R.

So it's SELECT FROM t WHERE true;

Now, let's get busy blaming Jepsen for using the tool wrong.

	▲	debugnik an hour ago \| parent [-]
		> therefore that whole WHERE clause doesn't exist either No, therefore the condition is unsatisfiable and equivalent to WHERE FALSE. And that's letting you ignore the SQL spec, which says the query is invalid and should return "Column not found" because the column name cannot be resolved. > We're comparing 4 and 5. Precedent? I really hope you're trolling, for your own sake.