On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost <sfr...@snowman.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to