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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> I do not see how you can propose this, which creates an explicit
Tom> equivalence between a plain null and an all-nulls row, and
Tom> simultaneously advocate that we change IS NULL to remove its
Tom> treatment of those things as equivalent.

Because the proposal to change IS NULL is a discussion point that I'm
not dogmatically committed to.

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). This
is far more likely to break existing code than simply allowing what was
previously an error case to work.

--
Andrew (irc:RhodiumToad)