3 ms·
First of all, you can shorten that to this: ((t1.f1 IS NULL AND t2.f2 IS NULL) OR (t1.f1 = t2.f2)) That's logically equivalent because TRUE OR UNKNOWN evalu
by da_chicken 7y ago
First of all, you can shorten that to this:
((t1.f1 IS NULL AND t2.f2 IS NULL) OR (t1.f1 = t2.f2))
That's logically equivalent because TRUE OR UNKNOWN evaluates to TRUE, while FALSE OR UNKNOWN evaluates to UNKNOWN, which is not TRUE and therefore gets excluded.
Second, the complicated one that shows up in MERGE or UPSERT operations is the other way:
((t1.f1 IS NULL AND t2.f2 IS NOT NULL) OR (t1.f1 IS NOT NULL AND t2.f2 IS NULL) OR (t1.f1 <> t2.f2))
Third, this is exactly why many RDBMSs support the IS [NOT] DISTINCT FROM syntax defined in ANSI SQL, which replaces the first:
t1.f1 IS NOT DISTINCT FROM t2.f2
Or this which replaces the second:
t1.f1 IS DISTINCT FROM t2.f2
MS SQL Server and MySQL don't, but Oracle and PostgreSQL do. It's been in the standard for over 20 years at this point. So it's not the language that sucks; it's your vendor.
- Pxtl 7y agoAnd then somebody negates your "is equal" because they want "not equal" statement and tears their hair out.