Yeah. That syntax has some big advantages, though. If we define that partition as START ('2014-01-01') INCLUSIVE END ('2014-12-31') INCLUSIVE, there's no way for the system to tell that the there's no gap between the that ending bound and the starting bound of the 2015 partition, because the system has no domain-specific knowledge that there is no daylight between 2014-12-31 and 2015-01-01. So if we allow things to be specified that way, then people will use that syntax and then complain when it doesn't perform quite as well as START ('2014-01-01') END ('2015-01-01'). Maybe the difference isn't material and maybe we don't care; what do you think?
It was a fight I didn't expect to win, and even if we don't get [x,x]-expressible partitions, at least we're not in the Oracle context-waterfall, where the lower bound of your partition is determined by the upper bound of the NEXT partition.
(I really don't want to get tied up adding a system for adding and subtracting one to and from arbitrary data types. Life is too short. If that requires that users cope with a bit of cognitive dissidence, well, it's not the first time something like that will have happened. I have some cognitive dissidence about the fact that creat(2) has no trailing "e" but truncate(2) does, and moreover the latter can be used to make a file longer rather than shorter. But, hey, that's what you get for choosing a career in computer science.)
That noise your heard was the sound of my dream dying.