Обсуждение: Executor question

While trying to construct testcases for a patch, I ran into this:

execAmi.c has a function ExecMayReturnRawTuples which indicates whether
a given plan might return tuples that come straight from a table rather
than having been projected.

InitPlan() uses this to force the addition of a junk filter to INSERT
or SELECT INTO queries that return raw tuples, with this comment:
* Initialize the junk filter if needed.  SELECT and INSERT queries need a* filter if there are any junk attrs in the
tlist. INSERT and SELECT* INTO also need a filter if the plan may return raw disk tuples (else* heap_insert will be
scribblingon the source relation!). UPDATE and
 

However, tracing through the code suggests that neither ExecInsert not
intorel_receive will modify a passed raw tuple - ExecInsert calls
ExecMaterializeSlot before heap_insert, and intorel_receive calls
ExecCopySlotTuple before heap_insert.

So is the ExecMayReturnRawTuples and corresponding ExecFilterJunk needed
at all? Or am I missing something?

-- 
Andrew (irc:RhodiumToad)

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> However, tracing through the code suggests that neither ExecInsert not
> intorel_receive will modify a passed raw tuple - ExecInsert calls
> ExecMaterializeSlot before heap_insert, and intorel_receive calls
> ExecCopySlotTuple before heap_insert.

> So is the ExecMayReturnRawTuples and corresponding ExecFilterJunk needed
> at all? Or am I missing something?

You might be right.  The forced-projection logic dates from a time
when ExecInsert actually would scribble right on the tuple in the
slot it was handed (look at 8.0 or so), but with the addition of
"virtual" tuple table slots the ExecMaterializeSlot call was needed,
and so we might not need the forced projection anymore.

It'd be cool if we could get rid of ExecMayReturnRawTuples
altogether ... I'll take a look.
        regards, tom lane