Re: [HACKERS] Adding support for Default partition in partitioning - Mailing list pgsql-hackers
From | Jeevan Ladhe |
---|---|
Subject | Re: [HACKERS] Adding support for Default partition in partitioning |
Date | |
Msg-id | CAOgcT0PH=Wo-TeqD_xJ7f=neBbST4RMeUWO3LyjbhC-CBiugLQ@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Adding support for Default partition in partitioning (Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>) |
List | pgsql-hackers |
Hi Rahila,
With your latest patch:
Consider a case when a table is partitioned on a boolean key.
Even when there are existing separate partitions for 'true' and
'false', still default partition can be created.
I think this should not be allowed.
Consider following case:
postgres=# CREATE TABLE list_partitioned (
a bool
) PARTITION BY LIST (a);
CREATE TABLE
postgres=# CREATE TABLE part_1 PARTITION OF list_partitioned FOR VALUES IN ('false');
CREATE TABLE
postgres=# CREATE TABLE part_2 PARTITION OF list_partitioned FOR VALUES IN ('true');
CREATE TABLE
postgres=# CREATE TABLE part_default PARTITION OF list_partitioned FOR VALUES IN (DEFAULT);
CREATE TABLE
The creation of table part_default should have failed instead.
Thanks,
Jeevan Ladhe
On Thu, Apr 6, 2017 at 9:37 PM, Keith Fiske <keith@omniti.com> wrote:On Thu, Apr 6, 2017 at 7:30 AM, Rahila Syed <rahilasyed90@gmail.com> wrote:Rahila SyedThank you,regarding operator used at the time of creating expression as default partition constraint. This was notified offlist by Amit Langote.Hello,Thanks a lot for testing and reporting this. Please find attached an updated patch with the fix. The patch also contains a fixCould probably use some more extensive testing, but all examples I had on my previously mentioned blog post are now working.Keith
pgsql-hackers by date: