On Wed, Jun 14, 2017 at 9:20 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > > By the way, I mentioned an existing problem in one of the earlier emails > on this thread about differing attribute numbers in the table being > attached causing predicate_implied_by() to give up due to structural > inequality of Vars. To clarify: table's check constraints will bear the > table's attribute numbers whereas the partition constraint generated using > get_qual_for_partbound() (the predicate) bears the parent's attribute > numbers. That results in Var arguments of the expressions passed to > predicate_implied_by() not matching and causing the latter to return > failure prematurely. Attached find a patch to fix that that applies on > top of your patch (added a test too).
+ * Adjust the generated constraint to match this partition's attribute + * numbers. Save the original to be used later if we decide to proceed + * with the validation scan after all. + */ + partConstraintOrig = copyObject(partConstraint); + partConstraint = map_partition_varattnos(partConstraint, 1, attachRel, + rel); + If the partition has different column order than the parent, its heap will also have different column order. I am not able to understand the purpose of using original constraints for validation using scan. Shouldn't we just use the mapped constraint expressions? BTW I liked the idea; this way we can keep part_6 in sync with list_parted2 even when the later changes and still manage to have different order of attributes. Although the CHECK still assumes that there is a column "a" but that's fine I guess. +CREATE TABLE part_6 ( + c int, + LIKE list_parted2, + CONSTRAINT check_a CHECK (a IS NOT NULL AND a = 6) +); +ALTER TABLE part_6 DROP c; -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers