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
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 |