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).
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-05-29 21:37:50|
|Subject: Re: PG 9.0 release timetable|
|Previous:||From: Tom Lane||Date: 2010-05-29 21:11:17|
|Subject: Re: Performance problem in textanycat/anytextcat |