From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Henk Enting <h(dot)d(dot)enting(at)mgrid(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch for check constraints using multiple inheritance |
Date: | 2010-07-30 14:32:15 |
Message-ID: | AANLkTi=21k7mS7rDk8UKugr8R9to38BBx-GGTZdeQS4j@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> The original design idea was that coninhcount/conislocal would act
>>> exactly like attinhcount/attislocal do for multiply-inherited columns.
>>> Where did we fail to copy that logic?
>
>> We didn't. That logic is broken, too.
>
> Uh, full stop there. If you think that the multiply-inherited column
> logic is wrong, it's you that is mistaken --- or at least you're going
> to have to do a lot more than just assert that you don't like it.
> We spent a *lot* of time hashing that behavior out, back around 7.3.
Well, I'm glad you spent a lot of time hashing it out, but you've got
a bug. :-)
Since the output in the previous email apparently wasn't sufficient
for you to understand what the problem is, here it is in more detail.
Initial setup:
DROP SCHEMA IF EXISTS test_inheritance CASCADE;
CREATE SCHEMA test_inheritance;
SET search_path TO test_inheritance;
CREATE TABLE level_0_parent (i int);
CREATE TABLE level_0_child (a text) INHERITS (level_0_parent);
CREATE TABLE level_1_parent() INHERITS (level_0_parent);
CREATE TABLE level_1_child() INHERITS (level_0_child, level_1_parent);
CREATE TABLE level_2_parent() INHERITS (level_1_parent);
CREATE TABLE level_2_child() INHERITS (level_1_child, level_2_parent);
Then:
rhaas=# \d level_2_child
Table "test_inheritance.level_2_child"
Column | Type | Modifiers
--------+---------+-----------
i | integer |
a | text |
Inherits: level_1_child,
level_2_parent
rhaas=# ALTER TABLE level_0_parent ADD COLUMN a_new_column integer;
NOTICE: merging definition of column "a_new_column" for child "level_1_child"
NOTICE: merging definition of column "a_new_column" for child "level_2_child"
NOTICE: merging definition of column "a_new_column" for child "level_2_child"
ALTER TABLE
rhaas=# ALTER TABLE level_0_parent DROP COLUMN a_new_column;
ALTER TABLE
rhaas=# \d level_2_child
Table "test_inheritance.level_2_child"
Column | Type | Modifiers
--------------+---------+-----------
i | integer |
a | text |
a_new_column | integer |
Inherits: level_1_child,
level_2_parent
Adding a column to the toplevel parent of the inheritance hierarchy
and then dropping it again shouldn't leave a leftover copy of the
column in the grandchild.
rhaas=# ALTER TABLE level_2_child DROP COLUMN a_new_column;
ERROR: cannot drop inherited column "a_new_column"
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Cousin | 2010-07-30 14:35:21 | Re: lock_timeout GUC patch - Review |
Previous Message | Tom Lane | 2010-07-30 14:23:27 | Re: patch for check constraints using multiple inheritance |