Hello, On Mon, May 22, 2017 at 11:29 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote:
> On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > 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? > PFA the patch which gives the default partition constraint as you have suggested. > > > > > 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? > > Dependency on list default patch: gram.y : adding the syntax partition.c: - default_index member in PartitionBoundInfoData; - check_new_partition_bound : the code for adding a partition after default has been completely reused. - isDefaultPartitionBound function is used. The structures are same but the handling of list and range is very different and the code mostly has the switch case construct to handle the 2 separately. I feel it could be taken separately. As suggested in the default list thread, I have created a partition_bound_has_default macro and avoided usage of has_default in range code. This has to be used for list as well. Another suggestion for list which has to be implemented in this patch in removal of PARTITION_DEFAULT. Ii have not done this in this version. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
default_range_partition.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
