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