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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
Date: 2016-07-23 14:49:18
Message-ID: 18501.1469285358@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> 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.

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

I think the theory behind the existing code here is that if the SRF wants
its output to be interpreted as an all-nulls row, it can perfectly well
return an all-nulls row. I wonder whether we should address this by
adjusting unnest's behavior instead.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2016-07-23 23:47:51 Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
Previous Message Andrew Gierth 2016-07-23 08:25:03 Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly