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-27 01:37:37 |
Message-ID: | 4240.1469583457@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:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-27 01:52:37 | Re: BUG #14226: pg_upgrade for 8.4 to 9.4 failed |
Previous Message | ganuri | 2016-07-27 00:57:25 | BUG #14265: inserting multiple rows via array notation gives error |