Tom Lane wrote: > Jeff Davis <pg...@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 <br...@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,
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
