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-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

In response to

Browse pgsql-bugs by date

  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