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!