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: (view raw or whole 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
The Enterprise Postgres Company

In response to


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-2015 The PostgreSQL Global Development Group