On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Well, unless we abandon transactional semantics for other MERGE
> statements, we should have a way that UPSERT logic continues to
> work if you don't match a suitable index; it will just be slower --
> potentially a lot slower, but that's what indexes are for.
I want an implementation that doesn't have unique violations,
unprincipled deadlocks, or serialization failures at READ COMMITTED. I
want it because that's what the majority of users actually want. It
requires no theoretical justification.
> I don't
> think we need a separate statement type for the one we "do well",
> because I don't think we should do the other one without proper
> transactional semantics.
That seems like a very impractical attitude. I cannot simulate what
I've been doing with unique indexes without taking an exclusive table
lock. That is a major footgun, so it isn't going to happen.
--
Peter Geoghegan