Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | CAM3SWZQpGUvLHZ3FAreKRgmNPFaihbmnNTT_SJxo=QeAR6u6hQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Список | pgsql-hackers |
On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs <simon@2ndquadrant.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@mail.gmail.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
В списке pgsql-hackers по дате отправления: