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.
Regards,
Jeff Davis
*** a/src/backend/executor/execUtils.c
--- b/src/backend/executor/execUtils.c
***************
*** 1309,1323 **** retry:
index_endscan(index_scan);
/*
! * 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,
- (errcode(ERRCODE_INTERNAL_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 ----
index_endscan(index_scan);
/*
! * 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
