Robert Haas wrote:
It seems to me that it should only recurse to its children
if the constraint was really added, rather than merged into an
existing constraint, because if it was merged into an existing
constraint, then the children already have it.
Yes. (then the children already have it -> already have it from the
current parent) - now I understand how AddRelationNewConstraints is
used, this effectively blocks > 1 times propagation to childs from the
same parent, and that is what our patch was written todo too.
OK, it looks like level_2_parent is actually irrelevant to this issue.
So here's a slightly simplified test case:
CREATE TABLE top (i int);
CREATE TABLE mid1 () INHERITS (top);
CREATE TABLE mid2 () INHERITS (top);
CREATE TABLE bottom () INHERITS (mid1, mid2);
CREATE TABLE basement () INHERITS (bottom);
This is, probably provable, the smallest case where this problem can
occur. Removing any table would mean that this bug is not hit anymore.
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.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
