Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly

This bug was reported three and a half years ago and apparently
ignored... but it came to my attention in the IS NULL discussion.

This patch doesn't address unnest() explicitly, rather it modifies
ExecMakeTableFunctionResult to treat an isnull return equivalently to an
all-nulls tuple. This isn't ideal, especially in view of the points
discussed in the other threads; it leaves these inconsistencies:

create type c1 as (a text, b numeric);
select u, u is distinct from null from (select unnest(array[null::c1,row('a',1)::c1,null::c1]) as u) s;
u | ?column?
-------+----------
| f
(a,1) | t
| f
(3 rows)

select u, u is distinct from null from unnest(array[null::c1,row('a',1)::c1,null::c1]) u;
u | ?column?
-------+----------
(,) | t
(a,1) | t
(,) | t
(3 rows)

But as far as I can tell, the spec actually requires that unnest cope
with nulls and produce actual columns; the syntax transformations result
in something roughly like:

SELECT (e).* FROM (SELECT a[i] AS e FROM ...)

and I don't see anything that licenses (e).* to fail just because a[i] is
the null value of a row type.

--
Andrew (irc:RhodiumToad)