Re: Proposal: revert behavior of IS NULL on row types

On Tue, Jul 26, 2016 at 11:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> 3. Andrew also revived the bug #7808 thread in which it was complained
> that ExecMakeTableFunctionResult should not fail on null results from
> functions returning SETOF composite. That's related only in that the
> proposed fix is to translate a plain NULL into ROW(NULL,NULL,...).
> I do not much like the implementation details of his proposed patch,
> but I think making that translation is probably better than failing
> altogether. Given the infrequency of field complaints, my recommendation
> here is to fix it in HEAD but not back-patch.
>

​Andrew's response also introduces an area for documentation improvement.

The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct
from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT
FROM".

In short, the former smooths out the differences between composite and
non-composite types while the later maintains their differences. While a
bit confusing I don't see that there is much to be done about it - aside
from making the distinction more clear at:

​https://www.postgresql.org/docs/devel/static/functions-comparison.html

Does spec support or refute this distinction in treatment?

CREATE TYPE twocol AS (col1 text, col2 int);
CREATE TYPE twocolalt AS (col1 text, col2 int);

SELECT
row(null, null)::twocol IS NULL,
null::twocol IS NULL,
null::twocol IS NOT DISTINCT FROM row(null, null)::twocol

Its at least worth considering whether to note that when comparing two
composite values using IS DISTINCT FROM that the comparison is unaware of
the composite type itself but performs an iterative comparison of each pair
of columns.

SELECT row(null, null)::twocol IS NOT DISTINCT FROM row(null,
null)::twocolalt

This is likely to matter little in practice given low odds of someone
accidentially comparing two physically identical but semantically different
composite types.

David J.

​