Re: Declarative partitioning

>
>
> It seems the way of specifying per-partition definition/constraint,
> especially for range partitioning, would have a number of interesting
> alternatives.
>
> By the way, the [USING opclass_name] bit is just a way of telling that a
> particular key column has user-defined notion of "ordering" in case of
> range partitioning and "equality" for list partitioning. The opclass would
> eventually determine which WHERE clauses (looking at operators, operand
> types) are candidates to help prune partitions. If we use the range_op
> range_literal::range_type notation to describe partition constraint for
> each partition, it might not offer much beyond the readability. We are not
> really going to detect range operators being applied in WHERE conditions
> to trigger partition pruning, for example. Although I may be missing
> something...
>

I don't think it's important that ranges be used internally for partition
pruning, though I don't see a reason why they couldn't. I was making the
case for range types being used at partition creation/declaration time,
because you were proposing new syntax to describe a range of values in text
when we already have that in range types. We should eat our own dog food.

But mostly, I wanted to make sure that range partitions could have
inclusive and exclusive bounds.

>
> > - No partitioning scheme survives first contact with reality. So you will
> > need a facility for splitting and joining existing partitions. For
> > splitting partitions, it's sufficient to require that the new partition
> > share either a upper/lower bound (with the same inclusivity/exclusivity)
> of
> > an existing partition, thus uniquely identifying the partition to be
> split,
> > and require that the other bound be within the range of the partition to
> be
> > split. Similarly, it's fair to require that the partitions to be joined
> be
> > adjacent in range. In both cases, range operators make these tests
> simple.
> >
>
> SPLIT/MERGE can be done in later patches/release, I think.
>

Later patches for sure. When a partition "fills up", it's a critical
performance issue, so the fewer steps needed to amend it the better.