Hello,
At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in
<b5e5d627-2fee-46f5-c219-9915416a9196@lab.ntt.co.jp>
> On 2016/07/22 0:38, Robert Haas wrote:
> > On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
> > <Langote_Amit_f8@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.
It seems to work as expected and message seems to be
reasonable. Test seems to be fine.
By the way I have one question.
Is it an expected configuration where tables in an inheritance
tree has different valid state on the same (check) constraint?
The check should be an equality if it's not.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center