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 12:48:52 |
Message-ID: | 29059.1469623732@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:
> I did think about that, but the existing code seems to go out of its way
> to build the tuplestore using the tupdesc obtained from the actual
> function result row, rather than the "expected" tupdesc, and it wasn't
> really obvious why that was.
As I noted in a comment, the key hazard would be that heap_form_tuple
copies the tupdesc's type identifier info into the created composite
Datum, thus possibly leading to a mixture of type IDs in the stored
tuples. But tuplestore stores MinimalTuples which omit that data,
so it doesn't matter. I have a feeling that the existing code here
might've been older than the changes to store MinimalTuples rather
than regular tuple datums in tuplestores; or at least, it was written
with the assumption that that was important.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-07-27 17:19:39 | Re: BUG #14150: Attempted to delete invisible tuple |
Previous Message | Andrew Gierth | 2016-07-27 03:59:50 | Re: BUG #7808: unnest doesn't handle nulls in array of composite typescorrectly |