Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Thanks Jeevan for reviewing.

On 2018/04/02 13:10, Jeevan Ladhe wrote:
> 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

Oops, fixed.

> 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

Sorry, didn't realize that it was already covered in create_tabel.sql.
Removed this one.

Attached updated patch. Adding this to the v11 open items list.

Thanks,
Amit