Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | CAM3SWZRnPqj-qvuqU9qRcpOwaisAxEyXD0zRnAGt5TDjwbmyJw@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 2:20 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > The claims that you can't get a duplicate key error with an UPSERT > are completely bogus, IMV. The *best* you can do is avoid them on > the index used for matching (unless you're willing to ignore > problem input rows or mangle the data in surprising ways to avoid > such an error on a second unique index). That's what I meant. Doing any more than that isn't useful. I want to do exactly that - no more, no less. If you're still not convinced, then I think the fact that no MERGE implementation does what you want should be convincing. It is *horrifically* complicated to make what you want work, if indeed it is technically feasible at all. Isn't this already complicated enough? We use different access techniques as you say. We do not use different types of snapshots. That seems like a pretty fundamental distinction. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: