Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

On Tue, Mar 3, 2015 at 12:05 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> My experimental branch works just fine (with a variant jjanes_upsert
>> with subxact looping), until I need to restart an update after a
>> "failed" heap_update() that still returned HeapTupleMayBeUpdated
>> (having super deleted within an ExecUpdate() call). There is no good
>> way to do that for ExecUpdate() that I can see, because an existing,
>> visible row is affected (unlike with ExecInsert()). Even if it was
>> possible, it would be hugely invasive to already very complicated code
>> paths.
>
> Ah, so we can't easily use super-deletion to back out an UPDATE. I had not
> considered that.

Yeah. When I got into considering making EvalPlanQualFetch() look at
speculative tokens, it became abundantly clear that that code would
never be committed, even if I could make it work.

>> I continue to believe that the best way forward is to incrementally
>> commit the work by committing ON CONFLICT IGNORE first. That way,
>> speculative tokens will remain strictly the concern of UPSERTers or
>> sessions doing INSERT ... ON CONFLICT IGNORE.
>
>
> Ok, let's try that. Can you cut a patch that does just ON CONFLICT IGNORE,
> please?

Of course. I'll have that for your shortly.

Thanks
-- 
Peter Geoghegan