On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemerson@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.
