Re: Ranges for well-ordered types - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Ranges for well-ordered types
Date
Msg-id 20060611152722.GD34196@pervasive.com
Whole thread Raw
In response to Re: Ranges for well-ordered types  (Michael Glaesemann <grzm@seespotcode.net>)
List 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@seespotcode.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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: bison version
Next
From: "Jim C. Nasby"
Date:
Subject: Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),