From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Date: | 2014-09-29 18:15:31 |
Message-ID: | CAM3SWZSf3kkUToRjYMwPcGO5UgmPPf71tBxzYO6vryNrQtDCPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 29, 2014 at 12:02 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-09-29 09:51:45 +0300, Heikki Linnakangas wrote:
>> That said, it would be handy if the syntax was closer to MERGE. Aside from
>> the concurrency issues, it does the same thing, right? So how about making
>> the syntax identical to MERGE, except for swapping the MERGE keyword with
>> e.g. UPSERT?
>
> I don't think that's a good idea. What most people are missing is an
> *easy* way to do upsert, that's similar to the normal INSERT. Not
> something with a pretty different syntax. That's why INSERT OR REPLACE
> and stuff like that was well adopted.
Agreed.
MERGE isn't the same other than the concurrency concerns, in any case.
It is driven by a join, which is very flexible, but also has problems
with concurrency (leaving aside the fact that in practice it doesn't
tend to work out well when it isn't an equi-join). UPSERT *has* to be
driven by something like a would-be unique violation, not an outer
join matching or not matching.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-09-29 18:28:07 | Re: open items for 9.4 |
Previous Message | Stephen Frost | 2014-09-29 18:01:06 | Re: jsonb format is pessimal for toast compression |