Ok. Here's a `gmake check` passing version that actually makes use of the new
AM entries in ExecInsert. Currently, AFAICS, this *only* provides an improvement
for systems that frequently insert duplicate rows. Perhaps not a common case,
but an improvement nonetheless, IMO.
I leaned in this direction(insert scans) for the handling of unique violations
as it seemed like a better idea to check ahead of time than to recover after
the fact. Being able to do checks ahead of time simply allows one to eliminate
the need for unwinding code. (Simply, think about not needing to heap_delete in
error log cases. [Well, potentially ;])
The problem with the AM no longer having the ability to make guarantees about
lock/state duration seems more or less unavoidable with this two-step process.
I'm not sure that I can actually resolve any concerns involved with the
transference of responsibility to the user of the AM.
Currently, in ExecInsert(), I not-so-safely assume that a index implements
scanforinsert if it's unique. This appears to be safe as far as all the
stock AMs are concerned. However, it will likely throw an exception for indexes
that are said to be unique whose AM doesn't implement scanforinsert
(thinking of external AMs?). I imagine this is something that I should fix, yes?
Besides that I think it's ready for review.
--
Regards, James William Pye
