Merlin Moncure <mmoncure@gmail.com> writes:
> here's a cut down example:
> with q as (select max(v) from (select 1 as v) q group by v) select q from q;
I traced through this example, and find that it's another issue in an
area we've hacked at before. ExecEvalVar, when it finds that it's
dealing with a whole-row Var of type RECORD, just assumes that the tuple
descriptor of the source TupleTableSlot is the correct descriptor for
the whole-row result. Now, in the case where the whole-row Var has a
named composite type, we have found that we have to go to quite some
lengths to deal with possible discrepancies in the desired and actual
rowtypes; in particular notice this comment:
* ... Also, we have to allow the case that the slot has * more columns than the Var's type,
becausewe might be looking * at the output of a subplan that includes resjunk columns. (XXX * it
wouldbe nice to verify that the extra columns are all * marked resjunk, but we haven't got access to the
subplan * targetlist here...)
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.
Getting hold of that tlist is going to be a bit messy, though. I think
what we can do is create a special ExprState variant for whole-row Vars
(which we'd need anyway to hold the JunkFilter), and have ExecInitExpr
store the "parent" PlanState pointer into it. Then at the first call
of ExecEvalVar, dig down to the appropriate tlist depending on what
type of PlanState we find ourselves running in. This shouldn't be
too painful because a whole-row Var can only appear in a simple scan
node, not an upper-level plan node, so there are not as many cases
to deal with as you might think.
regards, tom lane
