Re: Scanning for insert

James William Pye <pgsql(at)jwp(dot)name> writes:
> 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.

Is this really a good idea? The fundamental problem I see with it is
that it takes away the index AM's ability to make any guarantees about
its locking behavior, ie, how long locks will be held or what other
operations might intervene while holding them. It'll also require the
AM to save potentially large amounts of state between the two calls
(eg, an entire search path might be needed for GiST). Currently any
such state can live on the stack in local variables, but that won't
work if it has to be remembered until a later AM call. Lastly, what
happens if the caller loses control (due to elog) and never makes the
followup AM call?

> 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?).

If that's what you want, maybe a better answer is to simply allow
aminsert to return a uniqueness-conflict indication, rather than
raising the ereport for itself.

regards, tom lane