Scanning for insert

Greets,
[Ugh, sent one with uncompressed patch. Seems to be swallowed(No failure msg?).
Ignore it if it surfaces.]

The attached patch extends pg_am by adding two methods, "scan for insert" and
"insert from scan". These methods are meant to provide an index user with the
ability to do conditional insertions based on the results of a conclusive
locking scan--a scan that not only finds a match, but resolves its actual
existence(what _bt_check_unique does), and makes any necessary locks to warrant
later insertion by a call to insertfromscan. (It should also be noted that
insertions are aborted by giving the insertfromscan method an InvalidItemPointer
instead of adding another method, ie "abortinsertscan".)

I'm sending this to hackers instead of patches, because it's not complete(I know
it's broken in the some of the new places), and, most importantly, I want to
know if this is actually the appropriate general direction to travel in. Not to
mention that I have probably missed something and I hope that someone will give
me my due whackings with The Clue Stick. :P

These new index interfaces are meant to provide the necessary functionality
for doing conditional index insertions that will likely aid in any
implementation of error logging, and other features(merge?). I have failed to
find much discussion on this, so if there is a good thread about, please point
me at it.

The most recent discussion of something along these lines was Martijn's thread
about providing non-btree indexes with uniqueness:
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00541.php
(However, I doubt that this patch would actually help with deferred constraints
or giving GiST/hash uniqueness.)

This patch is mostly incremental, and doesn't make many alterations to existing
code for the time being; the most significant alteration was restructuring a bit
of _bt_check_unique(_bt_evaluate in this patch) to work for both scanforinsert
and doinsert.
(This is probably a good thing as this code is all pretty new to me.)

[Sorry about some of the whitespace changes in the patch, remnants from an
overzealous version.]

Any thoughts and directions would be appreciated.
--
Regards, James William Pye