Greg Stark <greg.stark@enterprisedb.com> writes:
> I don't understand what's wrong with the existing setup where DROP
> OIDS is a free operation.
It breaks things, in particular
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00332.php
We could kluge around that particular problem, but the objection
I have to doing so is I'm 100% certain it won't be the last such bug.
> It seems exactly equivalent to how we handle DROP COLUMN
It is just about exactly *unlike* DROP COLUMN, because in DROP COLUMN
we retain a memory that there used to be a column there. A close
emulation of DROP COLUMN would involve inventing some representation of
"oidisdropped", and going through every one of the multitudinous places
that special-case dropped columns in order to see if each one needs a
similar special case for dropped OIDs. The bug mentioned above stems
directly from not expecting a table to still contain OIDs after SET
WITHOUT OIDS, so I don't think this parallel is mistaken.
Note that I'm willing to lay a significant side bet that we still have
bugs of omission with dropped columns, too. But we'll fix those as we
come to them. I don't think it is worth making a similar open-ended
commitment of resources just to keep SET WITHOUT OIDS fast.
> ... where the
> natt field of the tuple disagrees with the tuple descriptor and any
> additional columns are implicitly null.
No, that's the mechanism that makes ADD COLUMN feasible (and indeed
pretty easy). DROP COLUMN is the far newer and uglier mess around
attisdropped.
regards, tom lane