Re: WIP: Range Types

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Range Types
Date: 2011-01-05 05:54:16
Message-ID: 1294206856.18031.3501.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-01-05 06:55:02 Re: We need to log aborted autovacuums
Previous Message Shigeru HANADA 2011-01-05 05:52:07 Re: SQL/MED - core functionality