On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga <yebhavi...@gmail.com> wrote: > Tom Lane wrote: >> >> Yeb Havinga <yebhavi...@gmail.com> writes: >> >>> >>> A.a_column B.a_column >>> | / >>> v v >>> C.a_column >>> C inherits from A and B. >>> >> >> Well, if A and B inherited the column from a common ancestor, he can >> easily do that. If not, maybe he should have thought harder before he >> started. I do NOT agree that issuing a rename against C is a sane way >> of dealing with this. >> > > Ok, I understand the intuition behind not wanting this kind of update. > > The root cause seems to center around multiple inheritance of the same > column without a common ancestor. Another way to approach the problem, is to > prevent the user to create a setup, i.e. when adding a column to B that > already exists in A, or when adding a inheritance relation A-C or B-c, if A > and B share column names. He could then get a hint he should add a common > ancestor with that column. This preemptively prevents problems with renames > and other changes.
It also breaks compatibility with previous releases for no particular reason. These cases are all marginal enough that it doesn't really make sense to change historical behavior; I think we should confine our efforts to fixing the bugs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
