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

This patch simply removes that sanity check, and leaves a comment in

        Jeff Davis
*** a/src/backend/executor/execUtils.c
--- b/src/backend/executor/execUtils.c
*** 1309,1323 **** retry:
! 	 * 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,
- 				 errmsg("failed to re-find tuple within index \"%s\"",
- 						RelationGetRelationName(index)),
- 		errhint("This may be because of a non-immutable index expression.")));
  	econtext->ecxt_scantuple = save_scantuple;
--- 1309,1320 ----
! 	 * Ordinarily, at this point the search should have found the
! 	 * inserted tuple if there was no conflict. However, there are
! 	 * some cases where a tuple may not conflict with itself, and
! 	 * therefore would _not_ have found itself in this search -- for
! 	 * instance, if the operator is <>.
  	econtext->ecxt_scantuple = save_scantuple;
Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to