From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Date: | 2013-10-15 18:11:14 |
Message-ID: | CAM3SWZRD6ufQ6Oa0cu5BZ-OYppnofRWJVLJ5HqYVDQ9BgZeTgQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 15, 2013 at 11:05 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> See the original e-mail in the thread for what I imagine idiomatic
> usage will look like.
>
> http://www.postgresql.org/message-id/CAM3SWZThwrKtvurf1aWAiH8qThGNMZAfyDcNw8QJu7pqHk5AGQ@mail.gmail.com
Note also that this doesn't preclude a variant with a more direct
update part (not that I think that's all that compelling). Doing
things this way was motivated by:
1) Serving the needs of logical changeset generation plugins, even if
Andres doesn't think that needs to be exposed through SQL. He and I
both want something that does this with low overhead (in particular,
no subtransactions).
2) Getting something effective into the next release. MERGE-like
flexibility seems like a very desirable thing. And the
implementation's infrastructure can be used by an eventual MERGE
implementation.
3) Being simple enough that huge bike shedding over syntax might not
be necessary. Making insert statements grow an update tumor is likely
to get messy fast. I know because I tried it myself.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-10-15 18:23:44 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Previous Message | Peter Geoghegan | 2013-10-15 18:05:09 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |