Re: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> This patch:

>> 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.

> 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);

Hmm, that's kinda ugly. The real reason there's a problem, IMHO,
is that the table contains tuples that don't match the rowtype
specification. We've tried to skate around this and pretend that
SET WITHOUT OIDS is cost-free, but it really isn't. I think this
bug needs to be regarded as a member of a class of probable bugs,
not an isolated error.

Could we get away with turning SET WITHOUT OIDS into a table-rewriting
operation that physically gets rid of the OIDs? The default has been
no-oids for long enough that I'm not convinced that we need to risk more
bugs in the name of keeping it a low-cost operation. (I note that we
could then also support SET WITH OIDS with about the same infrastructure.)

The alternative would probably be to treat a dropped OID column more
like a dropped user column, including an explicit mark in the catalogs
that "this table used to have OIDs" and special-casing all over the
place. Doesn't seem attractive.

regards, tom lane