On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemer...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
