Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
От | Geoff Winkless |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Дата | |
Msg-id | CAEzk6fdaHzGoGDbQe4cHfhu7MnKynaLd6e5C-_=drAcYYGkSdQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
|
Список | pgsql-hackers |
On 30 January 2015 at 21:58, Peter Geoghegan <pg@heroku.com> wrote: > On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: >> I suppose there's no reason why we couldn't use a no-op ON CONFLICT >> UPDATE anyway > > Right. IGNORE isn't really all that compelling for that reason. Note > that this will still lock the unmodified row, though. Mmmf. So I would have to make sure that my source tuples were unique before doing the INSERT (otherwise the first ON CONFLICT UPDATE for a tuple would block any other)? That's potentially very slow :( When you say that you can't add exclusion constraints later, do you mean from a coding point of view or just because people would get confused whether exclusion constraints could be IGNOREd or not? Geoff
В списке pgsql-hackers по дате отправления: