"Michael Richards" <miker@interchange.ca> writes:
> What are the cases where the current implementation does not handle it
> properly?
Inheritance.
CREATE TABLE parent (a, b, c);
CREATE TABLE child (z) INHERITS (parent);
ALTER TABLE parent ADD COLUMN (d);
With the current implementation you now have column order a,b,c,d in the
parent, and a,b,c,z,d in the child. This is seriously broken for a
number of reasons, not least being that pg_dump can't realistically be
expected to reproduce that state.
I don't really buy the complaint about "it'll take 2x the space". So
what? You'll likely expend that anyway trying to load reasonable data
into the new column. If we implemented ADD COLUMN in a less klugy
fashion, we could at least support loading a DEFAULT value into the
column (not to mention allowing it to be NOT NULL). More to the point,
I don't think that using 2x space is a sufficient justification for the
complexity and fragility that are imposed *throughout* the system in
order to make ADD COLUMN's life easy. You pay those hidden costs every
day you use Postgres, even if you've never done an ADD COLUMN in your
life.
> You could define a flag or something so a deleted column could be so flagged
> and ALTER TABLE DELETE COLUMN would run just as fast.
Hiroshi already tried that; you can find the vestiges of his attempt in
current sources (look for _DROP_COLUMN_HACK__). Again, the cost to the
rest of the system strikes me as far more than I care to pay.
In the end it's a judgment call --- my judgment is that making these
features fast is not worth the implementation effort and
understandability/reliability penalties that ensue. I think we would
be better off spending our effort on other things.
regards, tom lane