[ just a note for the archives ] I wrote: > Andrew Gierth <and...@tao11.riddles.org.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs