Skip site navigation (1) Skip section navigation (2)

Re: small exclusion constraints patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: small exclusion constraints patch
Date: 2010-05-30 16:56:27
Message-ID: AANLkTikKlaxEGprL1KAn9ounpuIXvThYGwTblSEmEr9T@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, May 30, 2010 at 10:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
>> On 2010-05-30 06:55 +0300, Robert Haas wrote:
>>> I've often wished for the ability to constrain a tale to hold just one
>>> row, so I don't find that use case implausible at all.
>
>> As I pointed out in
>> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01177.php , you
>> can already do that.
>
> Yes.  This is NOT about constraining a table to hold only one row.
> It's about requiring all its rows to hold the same value (in some
> column(s)), without predetermining exactly which value that will be.
> I think the use-case for that is really extremely narrow.

It probably is pretty narrow.  After all, exclusion constraints in
general are something that not everyone needs, and the ordinary use
case of preventing two intervals or regions from overlapping will
doubtless be far more common than this one.  Still, I'm not sure how
that's relevant.  The fact that not very many people will want to do
something is not a reason to prevent it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-05-30 16:59:25
Subject: Re: pg_trgm
Previous:From: Greg StarkDate: 2010-05-30 16:43:12
Subject: Re: Re: [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group