Re: Range types - Mailing list pgsql-hackers

From David Fetter
Subject Re: Range types
Date
Msg-id 20091215194919.GR25210@fetter.org
Whole thread Raw
In response to Re: Range types  (Scott Bailey <artacus@comcast.net>)
Responses Re: Range types  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Range types  (Scott Bailey <artacus@comcast.net>)
Re: Range types  (Jeff Davis <pgsql@j-davis.com>)
Re: Range types  (tomas@tuxteam.de)
List pgsql-hackers
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
> Jeff Davis wrote:
> >On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
> 
> Would it be OK if we handled float timestamp ranges as continuous
> and int64 timestamps discrete?

That sounds like a recipe for disaster.  Whatever timestamp ranges
are, float and int64 should be treated the same way so as not to get
"surprises" due to implementation details.

> You effectively lose the ability to build non-contiguous sets with
> continuous ranges. Which is integral to the work I'm doing (union,
> intersect, coalesce and minus sets of ranges)
> 
> As for the extra bits, would it be better to just require continuous
> ranges to be either [] or [)? But I don't know which would be
> preferred. My inclination would be toward [), but Tom seemed to
> indicate that perhaps [] was the norm.

[] makes certain operations--namely the important ones in
calendaring--impossible, or at least incredibly kludgy, to do.  I
think we ought to leave openness at each end up to the user,
independent of the underlying implementation details.

FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Closing out CommitFest 2009-11
Next
From: Tom Lane
Date:
Subject: Re: ProcessUtility_hook