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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org