Index AM API changes for deferability

I am reviewing the following patch:

http://archives.postgresql.org/message-id/8e2dbb700907071138y4ebe75cw81879aa513cf82a3@mail.gmail.com

In order to provide useful feedback, I would like to reach a consensus
on a possible index AM API change to make it easier to support
deferrable constraints for index access methods that enforce the
constraints themselves.

I am trying to word this question carefully, because there is a lot of
context: * Dean Rasheed is implementing deferrable unique constraints for BTree   (in the patch linked above) * Kenneth Marshall has indicated that he would like to implement    unique hash indexes in a way similar to the current btree    implementation:   http://archives.postgresql.org/pgsql-hackers/2009-07/msg00812.php   http://archives.postgresql.org/pgsql-hackers/2009-07/msg00834.php * I have a patch up for review that implements more general    constraints that are enforced outside of AM-specific code, and    therefore do not require index AM changes to support deferrable    constraints:   http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php

The btree unique code is already a "serious failure of modularity":
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00427.php

So, assuming that we support all of these features together, we have two
options that I see:
1. Extend the index AM API in a manner similar to Dean's patch.
2. Try to come up with some workaround to avoid changing the AM API

I was originally leaning toward approach #2 because I saw btree as the
only index AM that needed it, so extending the API seemed a little
excessive. However, seeing as it's potentially useful for unique hash
indexes, too, I am now leaning toward approach #1.

Also, we don't have performance numbers for either my feature or a
unique constraint implemented inside the hash index AM, so we don't know
whether that's a big win to enforce the constraint in the AM-specific
code or not.

So, should we proceed assuming an index AM API change, or try to avoid
it? If we should change the AM API, is Dean's API change acceptable?

Regards,Jeff Davis