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

Re: small exclusion constraints patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(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-29 21:16:59
Message-ID: AANLkTim3Ual2IPI03jkVTJsq14YTsMIVyLpcZNvGoyad@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, May 28, 2010 at 10:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> > Currently, the check for exclusion constraints performs a sanity check
>> > that's slightly too strict -- it assumes that a tuple will conflict with
>> > itself. That is not always the case: the operator might be "<>", in
>> > which case it's perfectly valid for the search for conflicts to not find
>> > itself.
>>
>> > This patch simply removes that sanity check, and leaves a comment in
>> > place.
>>
>> I'm a bit uncomfortable with removing the sanity check; it seems like a
>> good thing to have, especially since this code hasn't even made it out
>> of beta yet.  AFAIK the "<>" case is purely hypothetical, because we
>> have no index opclasses supporting such an operator, no?  How about just
>> documenting that we'd need to remove the sanity check if we ever did add
>> support for such a case?
>
> Done, with attached, applied patch.

The only disadvantage I see of just documenting this is that someone
might write a user-defined index opclass that works like this, and
they won't be able to use this until at least 9.1 (or at least, not
without patching the source).

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-05-29 21:37:50
Subject: Re: PG 9.0 release timetable
Previous:From: Tom LaneDate: 2010-05-29 21:11:17
Subject: Re: Performance problem in textanycat/anytextcat

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