Jaime Casanova <systemguards@yahoo.com> writes:
> The point of the core is they won't do it because
> they have things more important to do, or, the feature
> will never be part of the postgresql even if someone
> else contribute it.
We looked at this and decided that it would be vastly more trouble than
it's worth --- not only in terms of effort to implement the feature
originally, but in ongoing maintenance and risk of bug creation.
For instance, the original proposals about it required separating
"logical" and "physical" column numbers, so that a new column could be
added physically at the end but logically be earlier in the sequence.
This would be a huge amount of work to get done in the first place:
you'd have to look at essentially every single use of column numbers
in both the backend and every application and decide which flavor you
wanted to use at that place. And mistakenly using the wrong flavor
would be a permanent gotcha that could be expected to introduce new bugs
in future.
Given the 8.0 ALTER TABLE feature of being able to rewrite the whole
table, one could now think about doing it without decoupling logical
and physical numbers: just rewrite the table with the new column
inserted in the proper place. This moves the problem to a different
area, which is being sure you have updated every place in the system
catalogs and backend caches that references the old column numbers of
the renumbered columns. Again, doable in theory but a lot of work,
and it introduces a bug hazard every time someone changes these data
structures.
So, no we're not likely to do it ourselves, and we'd probably reject as
unmaintainable any patch to do it in either of the above ways. What's
needed to get the idea off the "forget it" list is a different
implementation plan that isn't going to create a maintenance headache.
regards, tom lane
