Re: ALTER TABLE modifications - Mailing list pgsql-patches

From Peter Eisentraut
Subject Re: ALTER TABLE modifications
Date
Msg-id Pine.LNX.4.44.0311141745130.4276-100000@peter.localdomain
Whole thread Raw
In response to Re: ALTER TABLE modifications  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE modifications  (Hannu Krosing <hannu@tm.ee>)
List pgsql-patches
Tom Lane writes:

> I believe the consensus was that automating what you could do by hand
> is still a step forward.

I don't recall that, but if so, I would like to revisit that consensus.

AFAICT, this patch does not buy us anything at all.  It's just a different
spelling of existing functionality.  We have never done that before.  It
just makes the system harder to maintain and use.  All commands should be
reasonably independent, or at least add some functionality of their own.

> It clearly would be better if we could relabel the logical column
> position after finishing the whole process, but I agree with Rod that
> that is an independent patch.  Combining them into one mega-patch
> doesn't sound like good engineering.

Good engineering would be if the logical column number patch comes first.
We cannot possibly leave this patch as is.  People expect in-place column
changes.  Things will break left and right, users will complain all over
the place if we offer a way to change a column, but yeah, by the way it
changes the structure of the table as well.  We've had these kinds of good
idea/right direction/better than nothing approaches in areas like DROP
COLUMN and CLUSTER already, and they were no good.  Except in this case,
"better than nothing" doesn't even apply, because there is already
something.

--
Peter Eisentraut   peter_e@gmx.net


pgsql-patches by date:

Previous
From: Rod Taylor
Date:
Subject: Re: ALTER TABLE modifications
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] heads up -- subtle change of behavior of new initdb