On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemerson@gmail.com> wrote:
> Hello,
>
> Many were in favour of the default partition for tables partitioned by range
> [1].
> Please find attached the WIP patch for the same which can be applied over
> the default_partition_v12.patch.
>
> Syntax: Same as agreed for list:
> CREATE PARTITION <part_name> PARTITION OF <parent_tbl> DEFAULT;
>
> Default Constraint:
> Negation constraints of all existing partitions.
>
> One case:
> CREATE TABLE range1 (a int, b int) PARTITION by range (a);
> CREATE TABLE range1_1 PARTITION OF range1 FOR VALUES FROM (1) TO (5);
> CREATE TABLE range1_2 PARTITION OF range1 FOR VALUES FROM (7) TO (10);
> CREATE TABLE range1_def PARTITION OF range1 DEFAULT;
> \d+ range1_def
> Table "public.range1_def"
> Column | Type | Collation | Nullable | Default | Storage | Stats target
> | Description
> --------+---------+-----------+----------+---------+---------+--------------+-------------
> a | integer | | not null | | plain |
> |
> b | integer | | | | plain |
> |
> Partition of: range1 DEFAULT
> Partition constraint: (((a < 1) OR (a >= 5)) AND ((a < 7) OR (a >= 10)))
Would it be more readable if this reads as NOT
(constraint_for_partition_1 || constraint_for_partition_2 ||
constraint_for_partition_3)? That way, the code to create
constraint_for_partition_n can be reused and there's high chance that
we will end up with consistent constraints?
>
> It still needs more work:
> 1. Handling addition of new partition after default, insertion of data, few
> more bugs
> 2. Documentation
> 3. Regression tests
>
I think, the default partition support for all the strategies
supporting it should be a single patch since most of the code will be
shared?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
