For strings and numeric types that are not integers, there is in theory a loss of power. If you want a partition that allows very value starting with 'a' plus the string 'b' but not anything after that, you are out of luck. START ('a') END ('b') INCLUSIVE would have done exactly what you want, but now you need to store the first string that you *don't* want to include in that partition, and what's that? Dunno. Or similarly if you want to store everything from 1.0 up to and including 2.0 but nothing higher, you can't, really.
Exactly. This is especially true for date ranges. There's a lot of cognitive dissonance in defining the "2014" partition as < '2015-01-01', as was the case in Oracle waterfall-style partitioning. That was my reasoning for pushing for range-ish syntax as well as form.
But who wants that? People who are doing prefix-based partitioning of their text keys are going to want all of the 'a' things together, and all of the 'b' things in another category. Same for ranges of floating-point numbers, which are also probably an unlikely candidate for a partitioning key anyway.
/me raises hand. We have tables with a taxonomy in them where the even data splits don't fall on single letter boundaries, and often the single string values have more rows than entire letters. In those situations, being able to express ['XYZ','XYZ'] is important. ['XYZ,'XZ') would let 'XYZ1' bleed into the partition and ['XYZ','XYZ1') lets in other values, and so I go chasing down the non-discrete set rabbit hole.
If we're worried about keywords, maybe a BOUNDED '[]' clause?
