Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Дата | |
Msg-id | CAM3SWZRZZahU0VJBnPr6zZ56W8Bk_7v1RFzVwq-BsDnKeV-3Rw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 (Geoff Winkless <pgsqladmin@geoff.dj>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
|
Список | pgsql-hackers |
On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > I appreciate the work you're doing and (as a user rather than a > pg-hacker) don't want to butt in but if it would be possible to allow > support for IGNORE for unique but not exclusion constraints that would > be really helpful for my own use cases, where being able to insert > from a dataset into a table containing unique constraints without > having to first check the dataset for uniqueness (within both itself > and the target table) is very useful. > > It's possible that I've misunderstood anyway and that you mean purely > that exclusion constraint IGNORE should be shelved until 9.6, in which > case I apologise. Well, the issue is that we can't really add exclusion constraints to the IGNORE case later. So the fact that we cannot do exclusion constraints kind of implies that we can either shelve IGNORE and maybe look at it later, or accept that we'll never support exclusion constraints with IGNORE. We'd then include IGNORE without exclusion constraint support now and forever. I tend to think that we'll end up doing the latter anyway, but I really don't want to add additional risk of this not getting into 9.5 by arguing about that now. It doesn't matter that much. > 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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: