Tom Lane wrote:
Andrew Dunstan <and...@dunslane.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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to