Thread: Adding columns in the middle of tables
--- Gaetano Mendola <mendola@bigfoot.com> escribió: > Jaime Casanova wrote: > > > Hi guys i was looking for the > > http://developer.postgresql.org/todo.php in order > >to view what things are you posponing for later > > versions > > but the entire developer.postgresql.org site is > > down. > > > > By the way, will be a way in postgresql 8 to add > > a column in a middle of a table. just curious. > > > > No IIRC. The core doesn't think this is a valid > > feature. > > I had in the past my reasons to ask for it too. If > > you > > have yours may be... Hi Gaetano, 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 _________________________________________________________ > Do You Yahoo!? > Información de Estados Unidos y América Latina, en > Yahoo! Noticias. > Visítanos en http://noticias.espanol.yahoo.com > _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com
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
> 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