Re: [HACKERS] Adding support for Default partition in partitioning - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Adding support for Default partition in partitioning
Date
Msg-id CA+TgmoZqbBkwMtQkok+cJxXU+zwSrwZ3kaCM81di+M8x1XsNfw@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
On Tue, Apr 11, 2017 at 9:41 AM, Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:
> I have checked for NULLs too, and the default partition can be created even
> when there are partitions for each TRUE, FALSE and NULL.
>
> Consider the example below:
>
> 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_3 PARTITION OF list_partitioned FOR VALUES IN
> (null);
> CREATE TABLE
> postgres=# CREATE TABLE part_default PARTITION OF list_partitioned FOR
> VALUES IN (DEFAULT);
> CREATE TABLE

In my opinion, that's absolutely fine, and it would be very strange to
try to prevent it.  The partitioning method shouldn't have specific
knowledge of the properties of individual data types.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] Undefined psql variables
Next
From: Tom Lane
Date:
Subject: [HACKERS] Inadequate parallel-safety check for SubPlans