]> granicus.if.org Git - postgresql/commit
As noted by Andrew Gierth, there's really no need any more to force a junk
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 26 Jul 2008 19:15:35 +0000 (19:15 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 26 Jul 2008 19:15:35 +0000 (19:15 +0000)
commita77eaa6a95009a3441e0d475d1980259d45da072
treee1f8f0f7e915ad440d9f7407a80d7b452034b133
parent94be06af76ac85e362c42bff5824a5cd04860934
As noted by Andrew Gierth, there's really no need any more to force a junk
filter to be used when INSERT or SELECT INTO has a plan that returns raw
disk tuples.  The virtual-tuple-slot optimizations that were put in place
awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
already copies the tuple if it's raw (and does so more efficiently than
a junk filter, too).  So get rid of that logic.  This in turn means that
we can throw away ExecMayReturnRawTuples, which wasn't used for any other
purpose, and was always a kluge anyway.

In passing, move a couple of SELECT-INTO-specific fields out of EState
and into the private state of the SELECT INTO DestReceiver, as was foreseen
in an old comment there.  Also make intorel_receive use ExecMaterializeSlot
not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
a tuple copy step in some cases.
src/backend/executor/execAmi.c
src/backend/executor/execMain.c
src/backend/executor/execUtils.c
src/include/executor/executor.h
src/include/nodes/execnodes.h