On Tue, Jul 26, 2016 at 11:10 AM, Tom Lane <t...@sss.pgh.pa.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.
