Re: Ranges for well-ordered types

On Wed, Jun 14, 2006 at 15:47:16 +0900,
Michael Glaesemann <grzm(at)seespotcode(dot)net> wrote:
>
> On Jun 13, 2006, at 13:25 , Bruno Wolff III wrote:
>
> >Date ranges are really closed open as well (as finite sets of
> >isolated points
> >are both open and closed). The only oddity would be that the date
> >used to
> >indicate the open end of the range might not be what the user expects.
>
> I think it's definitely a matter of interpretation. [2006-01-01,
> 2006-12-31] and [2006-01-01, 2007-01-01) both include the same days.
> Who's to say which is the "real" representation? For all practical

They are both real. In part my point was the reason the closed, closed form
works well for overlap checking is because the sets are also closed, open
and behave like that as well. (Though the user visible names are different.)

> purposes (i.e., what can be represented within the database)
> [2006-01-01 00:00:00+0, 2006-12-31 23:59:59] and [2006-01-01
> 00:00:00, 2007-01-01 00:00:00+0] represent the same timestamp(0) with
> time zone ranges as well. While one might idealize time to be
> continuous, as far as I know there isn't a way to represent time that
> way in a computer, at the very least, not in PostgreSQL.

Which is a good reason to used the Closed, Open definition. Then you don't
have to work about whether postgres has been built with integer timestamps
or the details of the floating point hardware your database is running on.

> And for the very reason that it might not be what the user expects,
> if there's a way to convert between closed-open and closed-closed as
> appropriate, I think it makes it much more use friendly to do so. For
> example, the closed-closed representation is equivalent to what
> BETWEEN does. It would be very nice to be able to provide sometime
> equivalent with ranges.

I don't think it is unreasonable to have a different external representation
for date ranges and timestamp ranges. It isn't conistant, but I think it is
more readily understandable. Internally, it will probably be better to use
closed, open for both to keep the code consistant to allow for reuse and
better understandibility at that level.

> As for the successor function itself: Any "exact" datatype, such as
> timestamp (at least with --enable-integer-datetimes), date, integer,
> or numeric, has some built-in precision anyway and a successor
> function follows quite directly from that precision. I don't see that
> as problematic or even very difficult.

The successor function for timestamp when not using integer datetimes is
going to depend on the underlying hardware. I think that will be a problem
unless you are planning to force the use of integer datetimes. I don't
think the project is ready for that yet, though in the long run I think it
is a better way to go.