On Fri, Oct 28, 2016 at 3:53 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> 4. I'm somewhat wondering if we ought to just legislate that the lower >> bound is always inclusive and the upper bound is always exclusive. >> The decision to support both inclusive and exclusive partition bounds >> is responsible for an enormous truckload of complexity in this patch, >> and I have a feeling it is also going to be a not-infrequent cause of >> user error. > > I thought we decided at some point to go with range type like notation to > specify range partition bound because of its flexibility. I agree though > that with that flexibility, there will more input combinations that will > cause error. As for the internal complexity, it's not clear to me whether > it will be reduced by always-inclusive lower and always-exclusive upper > bounds. We would still need to store the inclusive flag with individual > PartitionRangeBound and consider it when comparing them with each other > and with partition key of tuples.
We did. But I now think that was kind of silly. I mean, we also talked about not having a hard distinction between list partitioning and range partitioning, but you didn't implement it that way and I think that's probably a good thing. The question is - what's the benefit of allowing this to be configurable? For integers, there's absolutely no difference in expressive power. If you want to allow 1000-2000 with both bounds inclusive, you can just say START (1000) END (2001) instead of START (1000) END (2000) INCLUSIVE. This is also true for any other datatype where it makes sense to talk about "the next value" and "the previous value". Instead of making the upper bound inclusive, you can just end at the next value instead. If you were tempted to make the lower bound exclusive, same thing. 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. 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. So let's look at the other side. What do we gain by excluding this functionality? Well, we save a parser keyword: INCLUSIVE no longer needs to be a keyword. We also can save some code in make_one_range_bound(), RelationBuildPartitionDesc(), copy_range_bound(), partition_rbound_cmp(), and partition_rbound_eq(). Also, if we exclude this now as I'm proposing, we can always add it back later if it turns out that people need it. On the other hand, if we include it in the first version, it's going to be very hard to get rid of it if it turns out we don't want it. Once we release support for a syntax, we're kinda stuck with it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers