From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
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 07:11:41 |
Message-ID: | Pine.LNX.4.64.0702171009310.400@sn.sai.msu.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 16 Feb 2007, Alvaro Herrera wrote:
> 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.
RI-Tree (Relational intervar tree)
http://www.dbs.informatik.uni-muenchen.de/Forschung/CAD/presentations/RI-Tree.pdf
looks promising for that purposes.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru)
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-02-17 07:19:08 | Re: n-gram search function |
Previous Message | Tatsuo Ishii | 2007-02-17 04:26:34 | Re: [ANNOUNCE] Advisory on possibly insecure security definer functions |