Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS

Sorry, I was indeed thinking of newly added columns rather than
dropped columns. We define the row representation such that one may
have fewer rows than the tupledesc and how to interpret that in such a
way as to make adding nullable columns a convenient operation.

How is doing the same here and fixing a case where we weren't
following the definition any more of a kludge than how we handle newly
added columns? Which incidentally I don't think is at all kludgy.

I think what you propose would be a mistake. We want to encourage
people to move *away* from OIDS. - making drop kids prohibitively
expensive and adding an operation to add kids which we hope nobody
needs seems like heading in the wrong direction.

Sorry for top posting - in this case i'm using google mail's mobile
interface but it's no better about this and makes properly threading
responses nigh impossible.

On 2009-02-09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <greg(dot)stark(at)enterprisedb(dot)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
>

--
greg