Re: Range types - Mailing list pgsql-hackers

On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
> Scott Bailey <artacus@comcast.net> writes:
> > Because intervals (mathematical not SQL) can be open or closed at each 
> > end point we need to know what the next an previous value would be at 
> > the specified granularity. And while you can do some operations without 
> > knowing this, there are many you can't. For instance you could not tell 
> > whether two [] or () ranges were adjacent, or be able to coalesce an 
> > array of ranges.
> 
> This statement seems to me to demonstrate that you don't actually
> understand the concept of open and closed ranges.  It has nothing
> whatsoever to do with assuming that the data type is discrete;
> these concepts are perfectly well defined for the reals, for example.
> What it is about is whether the inclusion conditions are "< bound"
> or "<= bound".

Of course you can still define the obvious "contains" and "overlaps"
operators for a continuous range. But there are specific differences in
the API between a discrete range and a continuous range, which is what
Scott was talking about.

1. With discrete ranges, you can change the displayed
inclusivity/exclusivity without changing the value. For instance in the
integer domain, [ 5, 10 ] is the same value as [ 5, 11 ). This works on
both input and output. It is not possible to change the display for
continuous ranges.

2. With discrete ranges, you can get the last point before the range,
the first point in the range, the last point in the range, and the first
point after the range. These are more than enough to describe the range
completely. For continuous ranges, those functions will fail depending
on the inclusivity/exclusivity of the range. Practically speaking, you
would want to have a different set of accessors: start_inclusive(),
start_point(), end_point(), and end_inclusive(). However, those
functions can't be usefully defined on a discrete range.

We can't choose the API for continuous ranges as the API for discrete
ranges as well. If we did, then we would think that [5, 10] and [5, 11)
were not equal, but they are. Similarly, we would think that [5, 10] and
[11, 12] were not adjacent, but they are.

So there are certainly some user-visible API differences between the
two, and I don't think those differences can be hidden.

Regards,Jeff Davis