Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Hi,

I noticed that there were no tests covering this case causing 4dba331cb3
> to not notice this failure in the first place.  I updated your patch to
> add a few tests.  Also, I revised the comment changed by your patch a bit.
>

1. A minor typo:

+-- check that violating rows are correctly reported when attching as the
s/attching/attaching


2. I think following part of the test is already covered:

+-- trying to add a partition for 2 should fail because the default
+-- partition contains a row that would violate its new constraint which
+-- prevents rows containing 2
+create table defpart_attach_test2 partition of defpart_attach_test for
values in (2);
+ERROR:  updated partition constraint for default partition
"defpart_attach_test_d" would be violated by some row
+drop table defpart_attach_test;

IIUC, the test in create_table covers the same scenario as of above:

-- check default partition overlap
INSERT INTO list_parted2 VALUES('X');
CREATE TABLE fail_part PARTITION OF list_parted2 FOR VALUES IN ('W', 'X',
'Y');
ERROR:  updated partition constraint for default partition
"list_parted2_def" would be violated by some row

Regards,
Jeevan Ladhe