From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Abel Abraham Camarillo Ojeda <acamari(at)verlet(dot)org> |
Subject: | Extra check in 9.0 exclusion constraint unintended consequences |
Date: | 2011-07-05 16:26:50 |
Message-ID: | 1309883210.3012.46.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Abel Abraham Camarillo Ojeda | 2011-07-05 16:30:56 | Re: Extra check in 9.0 exclusion constraint unintended consequences |
Previous Message | Robert Haas | 2011-07-05 16:24:00 | Re: Range Types, constructors, and the type system |