Greg Stark <greg.st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
