On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga <yebhavinga@gmail.com> wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga <yebhavinga@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
