Re: [HACKERS] Happy column dropping - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Happy column dropping
Date
Msg-id 11573.948772632@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Happy column dropping  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: [HACKERS] Happy column dropping
RE: [HACKERS] Happy column dropping
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Happy column dropping