On 10 October 2011 18:53, Thom Brown <t...@linux.com> wrote: > On 10 October 2011 18:45, Jeff Davis <pg...@j-davis.com> wrote: >> On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote: >>> So the default boundaries should be '[]' as opposed to '[)' as it is >>> now. >> >> Would that vary between range types? In other words, do I bring back >> default_flags? >> >> If not, I think a lot of people will object. The most common use-case >> for range types are for continuous ranges like timestamps. And (as I >> pointed out in reply to Florian) there are good reasons to use the '[)' >> convention for those cases. > > I'm proposing it for discrete ranges. For continuous ranges, I guess > it makes sense to have "up to, but not including". The same boundary > inclusivity/exclusivity thing seems unintuitive for discrete ranges. > This has the downside of inconsistency, but I don't think that's > really a solid argument against it since their use will be different > anyway.
Okay, a real example of why discrete should be '[]' and continuous should be '[)'. If you book a meeting from 09:00 to 11:00 (tsrange), at 11:00 precisely it either becomes free or is available to someone else, so it can be booked 11:00 to 12:00 without conflict. If you have raffle tickets numbered 1 to 100 (int4range), and you ask for tickets 9 to 11, no-one else can use 11 as it aligns with the last one you bought. So for me, it's intuitive for them to behave differently. So yes, default behaviour would vary between types, but I didn't previously read anything on default_flags, so I don't know where that comes into it. Shouldn't it be the case that if a type has a canonical function, it's entirely inclusive, otherwise it's upper boundary is exclusive? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
