Extra check in 9.0 exclusion constraint unintended consequences - Mailing list pgsql-hackers

From Jeff Davis
Subject Extra check in 9.0 exclusion constraint unintended consequences
Date
Msg-id 1309883210.3012.46.camel@jdavis
Whole thread Raw
Responses Re: Extra check in 9.0 exclusion constraint unintended consequences
Re: Extra check in 9.0 exclusion constraint unintended consequences
List pgsql-hackers
In the 9.0 version of exclusion constraints, we added an extra check to
ensure that, when searching for a conflict, a tuple at least found
itself as a conflict. This extra check is not present in 9.1+.

It was designed to help diagnose certain types of problems, and is fine
for most use cases. A value is equal to itself (and therefore conflicts
with itself), and a value overlaps with itself (and therefore conflicts
with itself), which were the primary use cases. We removed the extra
check in 9.1 because there are other operators for which that might not
be true, like <>, but the use case is a little more obscure.

However, values don't always overlap with themselves -- for instance the
empty period (which was an oversight by me). So, Abel Abraham Camarillo
Ojeda ran into a rather cryptic error message when he tried to do that:

ERROR:  failed to re-find tuple within index "t_period_excl"
HINT:  This may be because of a non-immutable index expression.

I don't think we need to necessarily remove the extra check in 9.0,
because the workaround is simple: add a WHERE clause to the constraint
eliminating empty periods. Perhaps we could improve the error message
and hint, and add a note in the documentation.

Thoughts?

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Range Types, constructors, and the type system
Next
From: Abel Abraham Camarillo Ojeda
Date:
Subject: Re: Extra check in 9.0 exclusion constraint unintended consequences