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

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 08/04/2010 06:41 AM, Robert Haas wrote:
>>> Uh, really? Wow. You want to follow the inheritance hierarchy in
>>> both directions, both down and up? That seems like it could be
>>> confusing.
>
>> It seems more than confusing. It seems fundamentally wrong. It would
>> certainly be a violation of POLA.
>
> I agree, this idea seems completely nuts. It is *not* reasonable for
> an action applied to a child to change the definition of the parent.
Also not in the case that we're talking about here?

A.a_column B.a_column
| /
v v
C.a_column

C inherits from A and B.

The user wants to change a_column to better_name.

ALTER TABLE A RENAME COLUMN a_column TO better_name;
ERROR: could not rename column because an inherited child inherits the
same column from other inheritance parents
HINT: use CASCADE to rename the column in the other parents and their
childs as well

ALTER TABLE A RENAME COLUMN a_column TO better_name CASCADE;
(succeeds)

This doesn't seem nuts to me. After all, the set of columns with name
'a_column' is like a domain, in the sense that all names and types of
all three columns are the same. If the user wants to rename a_column,
with the current code he gets an inconsistent database. There is a patch
that prevents renaming in this case, and then the user could work around
it by adding an artificial relation from which A and B inherit, rename
a_column there and then remove that relation again. IMHO to allow the
rename if the user explicitly asks for it is more user friendly, with no
compromises at all. Since the upward inheritance relation scanning is
only used to gather the set of a_columns to be updated in the cascade
case, I do not see why this is nuts, nor why it should violate any
definition of inheritance. After all: all conditions regarding
inheritance I can think of are valid *after* the DDL update.

regards,
Yeb Havinga