Re: Adding columns in the middle of tables
От | Tom Lane |
---|---|
Тема | Re: Adding columns in the middle of tables |
Дата | |
Msg-id | 16305.1094338904@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Adding columns in the middle of tables (Jaime Casanova <systemguards@yahoo.com>) |
Ответы |
Re: Adding columns in the middle of tables
Re: Adding columns in the middle of tables |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: