Skip site navigation (1) Skip section navigation (2)

Re: patch for check constraints using multiple inheritance

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 20:38:30
Message-ID: 4C533846.3080101@gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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!


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-30 20:39:13
Subject: Re: On Scalability
Previous:From: Greg SmithDate: 2010-07-30 20:38:17
Subject: Re: On Scalability

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group