On Oct10, 2011, at 20:06 , Thom Brown wrote: > 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?
I'm not convinced by this. The question here is not whether which types of ranges we *support*, only which type we consider to be more *canonical*, and whether the bounds provided to a range constructor are inclusive or exclusive by *default*. Maybe ranges over discrete types are slightly more likely to be closed, and ranges over continuous types slightly more likely to be open. Still, I very much doubt that the skew in the distribution is large enough to warrant the confusion and possibility of subtle bugs we introduce by making the semantics of a range type's constructor depend on the definition of the range and/or base type. Especially since we're talking about only *6* extra characters to communicate the intended inclusivity/exclusivity of the bounds to the range constructor. Also, the distinction between types for which ranges should "obviously" be closed, and those for which they should "obviously" be half-open is nowhere as clear-cut as it seems at first sight. First, there's the type "date", which in my book is discrete. So we'd make date ranges closed by default, not half-open. And there's timestamp, which is continuous so we'd make its default half-open. That doesn't seem exactly intuitive to me. Second, there's int4 and float8, one discrete, one continuous. So would we make int4range(1, 2) include 2, but float8range(1.0, 2.0) *not* include 2.0? best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers