On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
