Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour. - Mailing list pgsql-hackers

From Jeevan Ladhe
Subject Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
Date
Msg-id CAOgcT0PEu_svcRP-kA8AyeOKyyGOtpBpSCGmcmemAjuW73iwOQ@mail.gmail.com
Whole thread Raw
In response to Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
List pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Michael Paquier
Date:
Subject: Re: Add default role 'pg_access_server_files'