A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD

This patch:

> commit 35ad25ad66fa3999bbc0bb59ca13cef3d750fb07
> Author: Tom Lane <tgl@sss.pgh.pa.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