Re: BUG #5240: Stable Functions that return a table type with a dropped column fail

[ just a note for the archives ]

I wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> I don't think it's particularly closely related to #4907.

> Yeah. I think the real problem is that set_subqueryscan_references
> is overly optimistic about how much work it has to do:

On further review it doesn't seem that fixing it there is very
practical. Currently, the Vars in the SubqueryScan's tlist and quals
have varno referencing the subquery RTE and attno matching the column
numbers of the function's declared result type. We can't just renumber
the attnos to match the actual subquery outputs without confusing the
heck out of EXPLAIN. It would be okay to change the attnos to match
if we also changed the varno to be OUTER --- then EXPLAIN would
understand the Vars as being references to the subplan's tlist. However
that would break the executor, in particular it would mean that
nodeSubqueryScan couldn't use the execScan.c facilities, since execScan
expects the expressions it's dealing with to reference the scan tuple
slot not the outer tuple slot.

I'm currently thinking that the best fix is to make inline expansion of
a SRF insert NULL columns into the expanded function tlist so that the
column numbering still matches up. This probably means that we'd not be
able to inline in certain cases, like if the SRF contains a UNION or
other operation where modifying the tlist changes the semantics.

regards, tom lane