Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
Index: src/backend/executor/execUtils.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/executor/execUtils.c,v
retrieving revision 1.171
diff -c -c -r1.171 execUtils.c
*** src/backend/executor/execUtils.c 26 Feb 2010 02:00:41 -0000 1.171
--- src/backend/executor/execUtils.c 29 May 2010 02:30:23 -0000
***************
*** 1310,1316 ****
/*
* We should have found our tuple in the index, unless we exited the loop
! * early because of conflict. Complain if not.
*/
if (!found_self && !conflict)
ereport(ERROR,
--- 1310,1317 ----
/*
* We should have found our tuple in the index, unless we exited the loop
! * early because of conflict. Complain if not. If we ever implement
! * '<>' index opclasses, this check will fail and will have to be removed.
*/
if (!found_self && !conflict)
ereport(ERROR,