Re: Constraint merge and not valid status - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Constraint merge and not valid status
Date
Msg-id b5e5d627-2fee-46f5-c219-9915416a9196@lab.ntt.co.jp
Whole thread Raw
In response to Re: Constraint merge and not valid status  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Constraint merge and not valid status  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: Constraint merge and not valid status  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Visual Studio 2015 and telemetry calls
Next
From: Craig Ringer
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol