Re: RFC: Temporal Extensions for PostgreSQL

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Warren Turkal <wt(at)penguintechs(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFC: Temporal Extensions for PostgreSQL
Date: 2007-02-17 08:50:41
Message-ID: 1171702241.3305.4.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval, R, 2007-02-16 kell 17:39, kirjutas Alvaro Herrera:
> Jim C. Nasby wrote:
> > My suggestion would be to focus on a period data type first and
> > foremost, as that's something that could be readily used by a lot of
> > folks. Of particular note, it's difficult to query tables that have
> > start_time and end_time fields to define a period; it's easy to screw up
> > the boundary conditions, and it's also hard to make those queries
> > perform well without going to extra lengths (such as defining a 'bogus'
> > GiST index on something like box(point(start,start),point(end,end)). And
> > it's not possible to do that in a way that avoids floating points and
> > their errors.
>
> FWIW there's already a type called tinterval that stores (start,end). I
> don't think it's very much documented; maybe it can be extended or used
> as base for a new, more complete and robust type, indexable in a more
> natural way, etc etc.

How easy/hard would it be to create unique indexes on tinterval (unique
here meaning non-overlapping) ?

Is tinterval meant to be open/closed at start and end ?

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2007-02-17 09:10:33 Re: n-gram search function
Previous Message Jeremy Drake 2007-02-17 08:23:17 Re: patch adding new regexp functions