On Wed, Jan 5, 2011 at 12:54 AM, Jeff Davis <pg...@j-davis.com> wrote: > On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote: >> On 1/4/11 10:18 AM, Jeff Davis wrote: >> > The main drawback here is that only a select group of people will be >> > defining discrete range types at all, because it would require them to >> > define a function first. Perhaps that's for the best, because, (as Tom >> > pointed out) we don't want someone using floats and then specifying a >> > granule of '0.01'. >> >> Frankly, I'm still not convinced that *anyone* will really need discrete >> range types > > Well, *need* is a standard that can never be met. But with something > like a date range, it's very possible that a discrete version matches > the real-world problem more closely than a continuous one. > > If you use only continuous ranges, then be careful to stick with exactly > one convention, or you will likely get wrong results (I think this point > has already been established). That sounds easy, but consider: > * If you want to know whether two ranges are adjacent (a common > requirement), then you need to use "[ )" or "( ]". > * If you need to map a single point into a range, the only thing that > makes sense is "[ ]". > * If your query contains current_date, you'll probably want ranges that > are either in "( ]" or "[ ]" form. > * If you are mixing data sets, they may use different conventions. > > You can work around all of these problems by making the query more > complex (and more error-prone). But I wouldn't like to give up on > discrete ranges for types where it really makes sense (dates, IPs, > integers).
+1. -- Robert Haas EnterpriseDB: 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
