Re: RFC: Temporal Extensions for PostgreSQL - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: RFC: Temporal Extensions for PostgreSQL
Date
Msg-id 1171822440.3305.30.camel@localhost.localdomain
Whole thread Raw
In response to Re: RFC: Temporal Extensions for PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RFC: Temporal Extensions for PostgreSQL  (Martijn van Oosterhout <kleptog@svana.org>)
Re: RFC: Temporal Extensions for PostgreSQL  (tomas@tuxteam.de)
List pgsql-hackers
Ühel kenal päeval, L, 2007-02-17 kell 11:26, kirjutas Tom Lane:
> Hannu Krosing <hannu@skype.net> writes:
> > How easy/hard would it be to create unique indexes on tinterval (unique
> > here meaning non-overlapping) ?
> 
> "Overlapping" is not an equality relation (it fails the transitive law),
> so I'm not entirely sure what "unique" means in this context ... 

Well, unique is usually defined as "not equal to any other". And "not
equal" also fails transitive law. So I can't see, how failing it makes
the defining the meaning of "unique" harder. What I mean by "unique
interval" here is an interval over unique points, or just an interval
which does not overlap any other interval.

If our uniqueness implementation relies on reverse operation (equality)
being transitive, then it can't be used for enforcing unique intervals.

But it should be trivial to test at insertion time if the interval
overlaps with any existing intervals, as it has to be inserted before
the previous unique interval and after the next interval. In other
words, unique interval index is a unique index of interval start times
with extra condition that interval end time is not >= than the next
intervals start.

> but I can promise you you can't make it work with btree.

Sorry to hear that. btree seemed like the best candidate for doing it.

-- 
----------------
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Plan invalidation design
Next
From: Tom Lane
Date:
Subject: Re: FETCH from scroll cursor does not return count in libpq PQcmdStatus