From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Henk Enting <h(dot)d(dot)enting(at)mgrid(dot)net>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Subject: | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) |
Date: | 2010-08-05 10:15:07 |
Message-ID: | 4C5A8F2B.4000504@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
/me ducks
regards,
Yeb Havinga
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-08-05 10:26:08 | Re: Review of Synchronous Replication patches |
Previous Message | Heikki Linnakangas | 2010-08-05 09:43:42 | Re: documentation for committing with git |