On Fri, Jul 22, 2016 at 1:10 AM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> On 2016/07/22 0:38, Robert Haas wrote:
>> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
>> <langote_amit...@lab.ntt.co.jp> wrote:
>>> Consider a scenario where one adds a *valid* constraint on a inheritance
>>> parent which is then merged with a child table's *not valid* constraint
>>> during inheritance recursion.  If merged, the constraint is not checked
>>> for the child data even though it may have some.  Is that an oversight?
>> Seems like it.  I'd recommend we just error out in that case and tell
>> the user that they should validate the child's constraint first.
> Agreed.
> Patch attached.  In addition to the recursion from parent case, this seems
> to be broken for the alter table child inherit parent case as well. So,
> fixed both MergeWithExistingConstraint (called from
> AddRelationNewConstraints) and MergeConstraintsIntoExisting (called from
> ATExecAddInherit). I had to add a new argument is_not_valid to the former
> to signal whether the constraint being propagated itself is declared NOT
> VALID, in which we can proceed with merging.  Also added some tests for
> both cases.

Well, on second thought, I'm no longer sure that this approach makes
sense.  I mean, it's obviously wrong for constraint-merging to change
the validity marking on a constraint, but that does not necessarily
imply that we shouldn't merge the constraints, does it?  I see the
downthread discussion saying that it's a problem if the parent's
constraint is marked valid while the child's constraint isn't, but I
don't quite understand why that situation would cause trouble.  In
other words, I see that the current situation is not good, but I'm not
sure I understand what's going on here well enough to be confident
that any of the proposed fixes are correct.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to