On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> I think the way to solve this is to do whatever it takes to get access >> to the subplan targetlist. We could then do something a bit cleaner >> than what the named-rowtype code is currently doing: if there are >> resjunk columns in the subplan targetlist, use the tlist to create a >> JunkFilter, and then pass the tuples through that. After that we can >> insist that the tuples don't have any extra columns. > > Here's a draft patch for that. It wasn't quite as ugly as I feared. > A lot of the apparent bulk of the patch is because I chose to split > ExecEvalVar into separate functions for the scalar and whole-row > cases, which seemed appropriate because they now get different > ExprState node types.
Thanks for that! Applying the patch and confirming the fix turned up no issues. I did a perfunctory review and it all looks pretty good: maybe ExecInitExpr could use a comment describing the InvalidAttrNumber check though...it's somewhat common knowledge that InvalidAttrNumber means row variables but it's also used to initialize variables before loops scans and things like that. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
