From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: INSERT ... ON CONFLICT syntax issues |
Date: | 2015-04-26 18:38:33 |
Message-ID: | CAM3SWZTa2OAUmUQbK39SKDYMQyX_yhjFrPTPA262=6OjX3erzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Ok, that makes sense.. So is the concern that an INSERT would end up
> getting default values while an UPDATE would preserve whatever's there?
>
> I don't see that as an issue.
I think it easily could be.
> Are you still against having a way to say "go forth and update whatever
> non-conflicting columns I've specified in the INSERT, if there is a
> conflict"..?
>
> Again, not saying it has to be done now, but it'd certainly be nice if
> we had it initially because otherwise the ORMs and "frameworks" of the
> world will be stuck supporting the more verbose approach for as long as
> we support it (~5 years..).
The more verbose approach is entirely necessary much of the time. For example:
insert into upsert_race_test (index, count)
values ('541','-1') on conflict update set count=TARGET.count + EXCLUDED.count;
Merging like this will be a very common requirement.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-04-26 18:43:47 | Re: INSERT ... ON CONFLICT syntax issues |
Previous Message | Stephen Frost | 2015-04-26 18:35:10 | Re: INSERT ... ON CONFLICT syntax issues |