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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers