Re: Default Partition for Range

Hello,

On Mon, May 22, 2017 at 11:29 AM, Ashutosh Bapat <
ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:

> On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemerson(at)gmail(dot)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