Re: except on nulls?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Kalchev <daniel(at)digsys(dot)bg>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: except on nulls?
Date: 2000-10-27 14:39:32
Message-ID: 29114.972657572@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Daniel Kalchev <daniel(at)digsys(dot)bg> writes:
> [ EXCEPT behaves oddly in the presence of NULLs ]

Yup, it does, because it's implemented like NOT IN, and NOT IN on a
set containing nulls can never return 'true', only 'false' or 'unknown'.
For example,
1 NOT IN (1,2,NULL)
is clearly FALSE. But
3 NOT IN (1,2,NULL)
is not clearly either true or false --- the null is effectively "I don't
know what this value is", and so it's unknown whether 3 is equal to it
or not. The SQL92 spec mandates that this NOT IN result be 'unknown'
(NULL), which is then treated like 'false' by EXCEPT. Net result:
nulls in EXCEPT's right-hand set cause its output set to be empty.

While this behavior is all according to spec for IN/NOT IN, it's *not*
according to spec for EXCEPT, because the spec defines UNION/INTERSECT/
EXCEPT in terms of a different concept, of rows being "distinct" or "not
distinct". NULLs are distinct from non-NULLs and so a null row behaves
the way you'd expect.

UNION/INTERSECT/EXCEPT are reimplemented for 7.1 in a way that behaves
according to spec. There's no simple patch for 7.0.* unfortunately.

> (but I sort of think this worked before...)

Could be. Before 7.0, IN/NOT IN were not up to spec on NULL handling
either, so EXCEPT probably worked differently in this case then.

> ERROR: Unable to identify an operator '<>' for types '_text' and '_text'
> You will have to retype this query using an explicit cast

There are no comparison operators for array types ...

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Sivagami . 2000-10-27 21:03:54 <database>.<table_name>
Previous Message Clayton C. 2000-10-27 11:36:04 benchmarks