A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD

This patch:

> commit 35ad25ad66fa3999bbc0bb59ca13cef3d750fb07
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Date: Sat Jul 26 19:15:35 2008 +0000
>
> 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.
>

made this test case crash:

CREATE TABLE xtable (padding char(2000)) WITH OIDS;
INSERT INTO xtable VALUES('1');
ALTER TABLE xtable SET WITHOUT OIDS;
INSERT INTO xtable (SELECT * FROM xtable);

with assertion failure:

TRAP: FailedAssertion("!(!(tup->t_data->t_infomask & 0x0008))", File:
"heapam.c", Line: 1782)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com