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).
Regards,Jeff Davis
