Re: patch for check constraints using multiple inheritance

On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting <h(dot)d(dot)enting(at)mgrid(dot)net> wrote:
>>> We ran into a problem on 9.0beta3 with check constraints using table
>>> inheritance in a multi-level hierarchy with multiple inheritance.
>
>> Thanks for the report.  This bug also appears to exist in 8.4; I'm not
>> sure yet how far back it goes.  I'm not so sure your proposed patch is
>> the right fix, though; it seems like it ought to be the job of
>> AddRelationNewConstraints() and MergeWithExistingConstraint() to make
>> sure that the right thing happens, here.
>
> 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. Using the OP's test setup:

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=# SELECT t.oid, t.relname, a.attinhcount
FROM pg_class t
JOIN pg_attribute a ON (a.attrelid = t.oid)
JOIN pg_namespace n ON (t.relnamespace = n.oid)
WHERE n.nspname = 'test_inheritance' AND a.attname = 'a_new_column'
ORDER BY t.oid;
oid | relname | attinhcount
-------+----------------+-------------
16420 | level_0_parent | 0
16423 | level_0_child | 1
16429 | level_1_parent | 1
16432 | level_1_child | 2
16438 | level_2_parent | 1
16441 | level_2_child | 3
(6 rows)

The attached patch (please review) appears to fix the coninhcount
case. I haven't tracked down the attinhcount case yet.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company