Re: Declarative partitioning grammar

Hi,

Jeff Cohen wrote:
> We did look at allowing general functions for partitioning and this was 
> one concern.  The other is that we want to enforce that a row only gets 
> inserted into a single partition, so we wanted a declarative syntax 
> where it was relatively easy to check that range and list specifications 
> don't overlap.

Why do you need to define a split point so ambiguously at all? Why not 
just give the DBA exactly *one* place to define the split point?

I don't think the separation into list, hash and range partitioning is 
adequate. What is the system supposed to do, if you try to insert a row 
which doesn't fit any of the values in your list or doesn't fit any of 
the ranges you defined?

I prefer a partitioning grammar which doesn't interfere with 
constraints. We all know how to define constraints. Please don't 
introduce a new, ambiguous way. A partitioning definition should be able 
to tell the target partition for *every* row which satisfies the 
constraints (the real ones, not ambiguous ones).

IMO, a single DDL command should only touch a single split point, i.e. 
split a table into two partitions, move the split point or remove the 
split point (joining the partitions again). Those are the only basic 
commands you need to be able to handle partitioning.

Sorry, but for my taste, the proposed grammar is too long per command, 
not flexible enough and instead ambiguous for split points as well as 
for constraints. To me it looks like repeating the mistakes of others.

Regards

Markus