Re: A bug in mapping attributes in ATExecAttachPartition()

On Wed, Jun 14, 2017 at 9:20 AM, Amit Langote
<Langote_Amit_f8@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