Adding columns in the middle of tables

=?iso-8859-1?q?Jaime=20Casanova?= <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

I want to clarify this.
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.

Maybe i am not capable of contribute it but i will
try if the feature will be become part of postgresql.

thanx in advance,
Jaime Casanova

The feature would be pretty easy to add in 8.1 (perhaps even within my
skills!), but the issue is that because it's a non-standard thing, I'd
like to know just how many other db's do it. If it's only MySQL, then
it's really touch and go as to whether I'd bother.

However...that said, I have a new philosophy of ease-of-use and this is
the 10^nth time someone has requested this feature, so I'd be inclinedto
give the people what they want!

Chris

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.

Ah, I hadn't considered the references issue. Does make it quite hard :)

Christopher Kings-Lynne wrote:

I want to clarify this.
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.

Maybe i am not capable of contribute it but i will
try if the feature will be become part of postgresql.

thanx in advance,
Jaime Casanova

The feature would be pretty easy to add in 8.1 (perhaps even within my
skills!), but the issue is that because it's a non-standard thing, I'd
like to know just how many other db's do it. If it's only MySQL, then
it's really touch and go as to whether I'd bother.

However...that said, I have a new philosophy of ease-of-use and this is
the 10^nth time someone has requested this feature, so I'd be inclinedto
give the people what they want!

Not always what people want is a good thing. People don't want pay
taxes for example...
However I'm with Tom Lane, this feature have a big impact on the code and
give a not so big improvement.

Regards
Gaetano Mendola

 --- Tom Lane <tgl@sss.pgh.pa.us> escribi�: 

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

Got it.

Obviously this is not a necesary feature and is a
feature that good design can do a very rare need.
I will think if there is another implementation plan
that can be used (but if *the core* didn't find it i
hardly will).

thanx a lot for the explanation,

Jaime Casanova

_________________________________________________________
Do You Yahoo!?
Informaci�n de Estados Unidos y Am�rica Latina, en Yahoo! Noticias.
Vis�tanos en http://noticias.espanol.yahoo.com