Re: patch for check constraints using multiple inheritance - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: patch for check constraints using multiple inheritance
Date
Msg-id 4C52F007.3010008@gmail.com
Whole thread Raw
In response to Re: patch for check constraints using multiple inheritance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch for check constraints using multiple inheritance
List pgsql-hackers
Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Since the output in the previous email apparently wasn't sufficient
>> for you to understand what the problem is, here it is in more detail.
>> ...
>> Adding a column to the toplevel parent of the inheritance hierarchy
>> and then dropping it again shouldn't leave a leftover copy of the
>> column in the grandchild.
>
> Actually, it probably should.  The inheritance rules were intentionally
> designed to avoid dropping inherited columns that could conceivably
> still contain valuable data.  There isn't enough information in the
> inhcount/islocal data structure to recognize that a multiply-inherited
> column is ultimately derived from only one distant ancestor, but it was
> agreed that an exact tracking scheme would be more complication than it
> was worth.  Instead, the mechanism is designed to ensure that no column
> will be dropped if it conceivably is still wanted --- not that columns
> might not be left behind and require another drop step.
This is not about dropping columns or not, but about proper maintenance 
of the housekeeping  of coninhcount, defined as "The number of direct 
inheritance ancestors this constraint has. A constraint with a nonzero 
number of ancestors cannot be dropped nor renamed".

Regard the following lattice (direction from top to bottom):

1
|\
2 3\|\ 4 5  \|   6

When adding a constraint to 1, the proper coninhcount for that 
constraint on relation 6 is 2. But the code currently counts to 3, since 
6 is reached by paths 1-2-4-5, 1-3-4-6, 1-3-5-6.

This wrong number is a bug.
> *Please* go re-read the old discussions before you propose tampering
> with this behavior.  In particular I really really do not believe that
> any one-line fix is going to make things better --- almost certainly
> it will break other cases.
Our (more than one line) patch was explicitly designed to walk from a 
specific parent to a child exactly once. It passes regression tests.

regards,
Yeb Havinga



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch for check constraints using multiple inheritance
Next
From: Robert Haas
Date:
Subject: Re: patch for check constraints using multiple inheritance