Hi,
Currently due to the way unique constraints are tied to btree there is
no way to allow GiST indexes to do the same thing. The thing I'm
specifically interested in is an index where you insert ranges
(start,end) and if unique, the index will complain if they overlap. As
a side-effect, this may make progress toward the goal of deferrable
unique indexes.
Part of the solution is to remove the layering violation from the btree
code, it really shouldn't be accessing the heap directly. What I'm
proposing is to move the bulk of _bt_check_unique into a new function
(say check_unique_index) in the general index machinary and have the
b-tree code do just:
check_unique_index( ctid of inserting tuple, ctid of possibly conflicting tuple)
The point being that GiST indexes could use exactly the same function
to check for duplicates. The function would return InvalidTransactionId
if there's no conflict, or an actual transaction id to wait on, just
like the btree code does now.
It would require some changes to the GiST code since a lot more of the
index may need to be checked for duplicates. I suppose in the general
case, since a key can appear in multiple places, the concurrency issues
could be difficult. I suppose you would insert your key first, then
check for duplicates thus ensuring that at least one of the two
conflicting transactions will see it.
Now, one side-effect is that you could build deferrable unique
constraints on top of this by having the check function always return
InvalidTransactionId but storing the conflicts for later checking. But
I first want to know if there are any real issues with the above.
Any thoughts?
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.