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

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> I think the theory behind the existing code here is that if the
>  Tom> SRF wants its output to be interpreted as an all-nulls row, it can
>  Tom> perfectly well return an all-nulls row.  I wonder whether we
>  Tom> should address this by adjusting unnest's behavior instead.

> One problem with changing unnest() is that it makes the operation
> array(select unnest(a)) return an array that's not equal to the original
> one (and which takes up a lot more space if there are many nulls).

Fair point.

I didn't much like the "initial_nulls" counter in your patch, but actually
there's no reason we can't just push an all-nulls row into the tuplestore
immediately on seeing a null, the same way as happens in the last-ditch
case at the bottom of ExecMakeTableFunctionResult.  I whacked that around
a bit and pushed it.

            regards, tom lane