From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | 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-28 20:31:46 |
Message-ID: | CAM3SWZQpGUvLHZ3FAreKRgmNPFaihbmnNTT_SJxo=QeAR6u6hQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> MERGE INTO tab USING VALUES ('foo')
> WHEN NOT MATCHED THEN
> INSERT (colB)
> WHEN MATCHED THEN
> UPDATE SET colB = NEW.p1
>
> and throwing "ERROR: full syntax for MERGE not implemented yet" if
> people stretch too far.
That isn't the MERGE syntax either. Where is the join?
I've extensively discussed why I think we should avoid calling
something upsert-like MERGE, as you know:
http://www.postgresql.org/message-id/flat/CAM3SWZRP0c3g6+aJ=YYDGYAcTZg0xA8-1_FCVo5Xm7hrEL34kw(at)mail(dot)gmail(dot)com#CAM3SWZRP0c3g6+aJ=YYDGYAcTZg0xA8-1_FCVo5Xm7hrEL34kw@mail.gmail.com
We *should* have a MERGE feature, but one that serves the actual MERGE
use-case well. That is an important use-case; it just isn't the one
I'm interested in right now.
FWIW, I agree that it wouldn't be much work to do this - what you
present here really is just a different syntax for what I have here
(which isn't MERGE). I think it would be counter-productive to pursue
this, though. Also, what about limiting the unique indexes under
consideration?
There was informal meeting of this at the dev meeting a in 2012.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-09-28 21:22:52 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Previous Message | Simon Riggs | 2014-09-28 20:17:17 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |