From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Ian Caulfield <ian(dot)caulfield(at)gmail(dot)com> |
Cc: | Michael Glaesemann <grzm(at)seespotcode(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Ranges for well-ordered types |
Date: | 2006-06-10 16:43:33 |
Message-ID: | 448AF6B5.1020308@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ian Caulfield wrote:
>
> On 6/10/06, *Michael Glaesemann* <grzm(at)seespotcode(dot)net
> <mailto:grzm(at)seespotcode(dot)net>> wrote:
>
> Returning to my original example, with a "date_range" type, the table
> could be defined as:
>
> create table teachers__schools_2
> (
> teacher text not null
> , school text not null
> , period date_range not null
> , primary key (teacher, school, period)
> );
>
> The original check constraint is handled by the date_range type and
> the two unique constraints are replaced by a single primary key
> constraint. Constraints for overlapping and continuity are still
> handled using constraint triggers, but are easier to implement using
> functions available to compare ranges rather than handling beginning
> and end points individually.
>
>
> I've done similar date range things by creating a composite type
> consisting of the lower and upper bounds, and then implementing a
> btree opclass where the comparator returns 0 if two ranges overlap -
> this allows a current btree index to enforce non-overlapping ranges,
> and allows indexed lookup of which range contains a particular value.
>
> Not sure whether this covers your scenario, but it works fairly well
> for me :)
Why not define a start_date and end_date to determine range, and then
use the date overlap functions in postgresql?
Joshua D Drake
>
> Ian
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2006-06-10 16:49:49 | Re: Ranges for well-ordered types |
Previous Message | Greg Stark | 2006-06-10 16:43:17 | Re: ADD/DROP INHERITS |