On Thu, Sep 14, 2017 at 4:03 AM, Jeevan Ladhe <jeevan.la...@enterprisedb.com> wrote: > Thanks Amit for reviewing. >> Patch looks fine to me. By the way, why don't we just say "Can we skip >> scanning part_rel?" in the comment before the newly added call to >> PartConstraintImpliedByRelConstraint()? We don't need to repeat the >> explanation of what it does at the every place we call it. > > I have changed the comment. > PFA.
I'm probably missing something stupid, but why does this happen? ALTER TABLE list_parted2 ATTACH PARTITION part_7 FOR VALUES IN (7); -INFO: partition constraint for table "list_parted2_def" is implied by existing constraints ERROR: partition constraint is violated by some row Based on the regression test changes made up higher in the file, I'd expect that line to be replaced by two lines, one for list_parted2_def_p1 and another for list_parted2_def_p2, because at this point, list_parted2_def is a partitioned table with those two children, and they seem to have appropriate constraints. list_parted2_def_p1 has Check constraints: "check_a" CHECK (a = ANY (ARRAY[21, 22])) list_parted2_def_p2 has Check constraints: "check_a" CHECK (a = ANY (ARRAY[31, 32])) Well, if a is 21 or 22 for the first, or 31 or 32 for the second, then it's not 7. Or so I would think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers