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!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
