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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
