Re: A bug in mapping attributes in ATExecAttachPartition()

On Wed, Jun 14, 2017 at 9:20 AM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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