Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly |
| Дата | |
| Msg-id | 18501.1469285358@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
| Ответы |
Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly
|
| Список | pgsql-bugs |
Andrew Gierth <andrew@tao11.riddles.org.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
В списке pgsql-bugs по дате отправления: