Re: [HACKERS] Happy column dropping

At 10:57 PM 1/24/00 -0500, Tom Lane wrote:
>Don Baccus <dhogaza@pacifier.com> writes:

>> Correct?  (again, to see if my eyeballs and brain are working in synch
>> tonight)

>Yup, that's about the size of it.

Phew!  I'm sane!  

>  ADD COLUMN doesn't actually touch the
>table itself, so it can only add a column that's initially all NULLs.
>And even this depends on some uncomfortable assumptions about the
>robustness of heap_getattr().

Yeah...that was my thought...you did notice I included the word
"kludge", yeah?  

>  I have always wondered whether it works
>if you ADD COLUMN a 33'rd column (or anything that is just past the
>next padding boundary for the null-values bitmap).

Way beyond my knowledge of things today, but if you REALLY CARE, I
could probably figure it out :)

>Another problem with it is seen when you do a recursive ADD COLUMN in
>an inheritance tree.  The added column has the first free column number
>in each table, which generally means that it has different numbers in
>the children than in the parent.  There are some kluges to make this
>sort-of-work for simple cases, but a lot of stuff fails unpleasantly
>--- Chris Bitmead can show you some scars from that, IIRC.

I think this probably explains some of the editorial comments about the
code.  There seem to be some added by "XXX" - is that person part of the
current clan of developers?  Comments like "This code is a crock because..."

>> Does your comment imply that it's planned to change this, i.e. actually
>> add the new column to each tuple in the relation rather than use the
>> existing, somewhat elegant hack?
>
>That's what I would like to see: all the children should have the
>same column numbers for all columns that they inherit from the parent.

>(Now, this would mean not only physically altering the tuples of
>the children, but also renumbering their added columns, which has
>implications on stored rules and triggers and so forth.  It'd be
>painful, no doubt about it.  Still, I'd rather pay the price in the
>seldom-used ADD COLUMN case than try to deal with out-of-sync column
>numbers in many other, more commonly exercised, code paths.)

Yeah...though I don't know the code well enough to comment on the pain,
in the wider, more general sense I totally agree.  I don't think 
efficiency of ADD COLUMN (or DROP for that matter) should be of paramount
concern, even though Oracle gives a separate quick DROP option similar to
what's being discussed as an alternative to COPY/RENAME.

My discomfort with the latter has more to do with the dropping of 
constraints (and I've read enough of the code to see that rebuilding
them might be a worthy subject for a Hitchcock film)

Cool...please be patient with me as I work my way through this stuff
in my spare time.  

And, Peter, if you're reading this, please be assured that my criticisms
are meant only in the context of wanting to see this open source database
become an Oracle (or other) slayer in at least a segment of the marketplace.
On its merits, not the price differential.  If I'm harsh on things that I
feel don't quite meet the mark, please don't take it personally.

And if I'm proven wrong, I'm always more than willing to admit it far
and wide, and to apologize in public.  

I just want to see debate over the "howtos" based on merit, that's it.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.