Re: Ranges for well-ordered types

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Michael Glaesemann <grzm(at)seespotcode(dot)net>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ranges for well-ordered types
Date: 2006-06-11 15:27:22
Message-ID: 20060611152722.GD34196@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 11, 2006 at 03:22:55PM +0900, Michael Glaesemann wrote:
>
> On Jun 11, 2006, at 14:45 , Bruno Wolff III wrote:
>
> >On Sun, Jun 11, 2006 at 10:18:11 +0900,
> > Michael Glaesemann <grzm(at)seespotcode(dot)net> wrote:
> >>
> >>Time (and timestamp) is a bit of a issue conceptually. The "default"
> >>successor function would depend on the precision of the timestamp.
> >
> >And in the ideal case it doesn't exist. That is why I think a
> >closed, open
> >interval is a better way to go.
>
> How would you go about converting a closed-open representation to a
> closed-closed representation for display purposes? Or inserting data
> that is provided in closed-closed representation?

Perhaps it makes more sense to consider the four possibilities
{ ( ), ( ], [ ), [ ] }
as different data types.

I realize that mathematically, there's probably plenty of reasons to
convert between closed and open on both ends (though I admit I can't
think of any reason to do this), but my focus is on what I believe to be
(by far and away) the most common PostgreSQL use case: defining
timestamp ranges. And that's something that needs to be closed, open.
(Sadly, I see people mess that up frequently.)

If this case can be well satisfied by an interval type that depends on a
sucessor function without a bunch of complexities (in code or
operation), then that's great. I'm worried that that's not the case (the
issue of various timestamp precisions is worrying enough by itself), and
I'd much rather see a solid closed, open interval added than nothing at
all.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-06-11 15:29:35 Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Previous Message Tom Lane 2006-06-11 15:21:20 Re: bison version