[HACKERS] A bug in mapping attributes in ATExecAttachPartition()

In ATExecAttachPartition() there's following code

13715         partnatts = get_partition_natts(key);
13716         for (i = 0; i < partnatts; i++)
13717         {
13718             AttrNumber  partattno;
13719
13720             partattno = get_partition_col_attnum(key, i);
13721
13722             /* If partition key is an expression, must not skip
validation */
13723             if (!partition_accepts_null &&
13724                 (partattno == 0 ||
13725                  !bms_is_member(partattno, not_null_attrs)))
13726                 skip_validate = false;
13727         }

partattno obtained from the partition key is the attribute number of
the partitioned table but not_null_attrs contains the attribute
numbers of attributes of the table being attached which have NOT NULL
constraint on them. But the attribute numbers of partitioned table and
the table being attached may not agree i.e. partition key attribute in
partitioned table may have a different position in the table being
attached. So, this code looks buggy. Probably we don't have a test
which tests this code with different attribute order between
partitioned table and the table being attached. I didn't get time to
actually construct a testcase and test it.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company