Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | CAM3SWZSmn90B_QQC2XcVuT=ceTtW9Y4rYmfi7MAh=nQg9g-U5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: