Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
От | Jeevan Ladhe |
---|---|
Тема | Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour. |
Дата | |
Msg-id | CAOgcT0PEu_svcRP-kA8AyeOKyyGOtpBpSCGmcmemAjuW73iwOQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour. (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
|
Список | 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 по дате отправления: