Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 719A6632C3B;
	Thu,  2 Apr 2009 17:07:09 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 07716-07; Thu,  2 Apr 2009 17:07:06 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30])
	by mail.postgresql.org (Postfix) with ESMTP id D662C632545;
	Thu,  2 Apr 2009 17:07:05 -0300 (ADT)
Received: by yx-out-2324.google.com with SMTP id 8so484964yxm.73
	for <multiple recipients>; Thu, 02 Apr 2009 13:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=0byisNf3LAKfo8KbHyUyMw7g08gmyB/C337dgPU+XYk=;
	b=n5iP+cqQReM1795eJEsZ1gyMoiuriCCGWFF1L+yHqyet1Jdws5b7ZSJJazaCrSOCRX
	K2g80nOrEBZANi3VTLYeDQ+8PhqdOgqG7UtSngO752sgfS4KydEdnDlj1BJzhxYEGaMo
	E2LTYSOuDZG0+LWDKnRb+b0dNtLx175dMHvNk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=keUU/4FrJmDSK4MFHy2vzwyVK251xNonOFG/tzDLIU6lyC6AOQbmw8pQXieS50grq/
	OG8fYsQxV6nN/wVv3uoMyN+dLwmhdZESNpA5zD69LAzv+ygiBGY+sDenloP4/inLudmj
	pqDCusUAUumkqBRuoEnc71ki8UMtdhQsaGXks=
MIME-Version: 1.0
Received: by 10.100.11.14 with SMTP id 14mr800037ank.89.1238702824863;
 Thu, 02
	Apr 2009 13:07:04 -0700 (PDT)
In-Reply-To: <49D50ABA.1050301@enterprisedb.com>
References: <49CA7A4D.8040206@agliodbs.com>
	<86CCDB96-2919-4437-952C-43DE4F125EC1@kineticode.com>
	<49D4C9B0.1060309@wrkhors.com>
	<5BAA6B5F-67DB-499B-ACB7-ABA1AC52976D@kineticode.com>
	<49D4FB25.8060400@agliodbs.com> <49D501C2.8060208@enterprisedb.com>
	<1238697453.29661.13.camel@dell.linuxdev.us.dell.com>
	<49D50ABA.1050301@enterprisedb.com>
Date: Thu, 2 Apr 2009 16:07:04 -0400
Message-ID: <603c8f070904021307h5d9fc9a6oa29183aee7e77fd9@mail.gmail.com>
Subject: Re: [HACKERS] Mentors needed urgently for SoC &
	PostgreSQL Student Internships
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Josh Berkus <josh@agliodbs.com>,
	"David E. Wheeler" <david@kineticode.com>, lembark@wrkhors.com,
	pgsql-hackers@postgresql.org, pgsql-www@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200904/8
X-Sequence-Number: 16875

On Thu, Apr 2, 2009 at 2:58 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Also, it would be nice to generalize the thing so that it works not only
> with intervals of time, but also floats, integers, numerics etc. The concept
> of an interval is not really tied to timestamps, even though that's probably
> the most common use case in the business world.

Suddenly this thread has my undivided attention.

A does-not-overlap operator would be awesome.   A does-not-overlap
index on a column whose value is a range would be awesome beyond
words.

As a simple example, consider an application whose job is to allocate
subnets out of some larger IP block.  Today, I typically handle cases
of this type by defining triggers that generate the ends of the range
and all the intermediate values and insert them into a side table with
a unique index.  It's really the pits, and unworkable for large
ranges.

...Robert