Re: patch for check constraints using multiple inheritance

Yeb Havinga wrote:
> Robert Haas wrote:
>> This still leaves open the question of what to do about the similar
>> case involving attributes:
>>
>> That problem looks significantly more difficult to solve, though.
>>   
> I'm looking at ATPrepAddColumn right now, where there is actually some 
> comments about getting the right attinhcount in the case of multiple 
> inherited children, but it's the first time I'm looking at this part 
> of PostgreSQL and it needs some time to sink in. It looks a bit like 
> at the place of the comment /* child should see column as singly 
> inherited */, maybe the recursion could be stopped there as well, i.e. 
> not only setting inhcount to 1, but actually adding the child relation 
> one time to the wqueue.
I believe the crux is to stop double recursion from a parent in 
ATOneLevelRecursion. I did a quick test by adding a globally defined

static List *visitedrels = NIL;

together by adding in front of ATOneLevelRecursion this:

    if (list_member_oid(visitedrels, relid))
        return;
    visitedrels = lappend_oid(visitedrels, relid);

Running Roberts example gives the correct attinhcount for the basement.

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_table_column'
ORDER BY oid;

  oid  | relname  | attinhcount
-------+----------+-------------
 16566 | top      |           0
 16569 | mid1     |           1
 16572 | mid2     |           1
 16575 | bottom   |           2
 16578 | basement |           1

regards,
Yeb Havinga

PS: forgot to say thanks for looking into this problem earlier in the 
thread. Thanks!