Robert Haas <robertmh...@gmail.com> writes: > On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Uh, full stop there. If you think that the multiply-inherited column >> logic is wrong, it's you that is mistaken --- or at least you're going >> to have to do a lot more than just assert that you don't like it. >> We spent a *lot* of time hashing that behavior out, back around 7.3.
> Since the output in the previous email apparently wasn't sufficient > for you to understand what the problem is, here it is in more detail. > ... > Adding a column to the toplevel parent of the inheritance hierarchy > and then dropping it again shouldn't leave a leftover copy of the > column in the grandchild. Actually, it probably should. The inheritance rules were intentionally designed to avoid dropping inherited columns that could conceivably still contain valuable data. There isn't enough information in the inhcount/islocal data structure to recognize that a multiply-inherited column is ultimately derived from only one distant ancestor, but it was agreed that an exact tracking scheme would be more complication than it was worth. Instead, the mechanism is designed to ensure that no column will be dropped if it conceivably is still wanted --- not that columns might not be left behind and require another drop step. *Please* go re-read the old discussions before you propose tampering with this behavior. In particular I really really do not believe that any one-line fix is going to make things better --- almost certainly it will break other cases. Being materially more intelligent would require a more complex data structure. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers