Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)

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