| From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04 10:54:59 |
| Message-ID: | 4C594703.20103@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas wrote:
> On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>
>>> If child inherits column A from parent1 and parent2, and it is then
>>> renamed to B in parent2, what should the name be in the child after
>>> the rename is completed?
>>>
>> The column should be renamed to B in parent2, child and parent1.
>>
>
> Uh, really? Wow. You want to follow the inheritance hierarchy in
> both directions, both down and up? That seems like it could be
> confusing.
>
Yes, the idea is to follow the up direction in the case of column
changes, only if the column is already present in another parent. To
avoid confusion we could block the first attempt of a change with a
message other parents exists, and the hint to add e.g. CASCADE to update
the definition in the other parent as well.
-- Yeb
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2010-08-04 11:39:11 | Proposal / proof of concept: Triggers on VIEWs |
| Previous Message | Yeb Havinga | 2010-08-04 10:41:24 | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) |