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}  (Kevin Grittner <kgrittn@ymail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)