Re: [HACKERS] Happy column dropping

Don Baccus <dhogaza@pacifier.com> writes:
> Just a reality check for my learning of the internals.  Out of curiousity
> I coincidently have spent the last hour looking to see how add column's
> implemented.  It doesn't appear to do anything other than the new attribute
> to the proper system table.  heap_getattr() just returns null if you ask
> for an attribute past the end of the tuple.  

> This would appear to be (at least one reason) why you can't add a "not null"
> constraint to a column you're adding to an existing relation, or set the
> new column to some non-null default value.

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

Yup, that's about the size of it.  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().  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).

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.

> 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.)
        regards, tom lane