On Sun, Jul 20, 2014 at 10:41 PM, Craig Ringer wrote:
> I'd be very keen to see atomic upsert in Pg. Please Cc me on any patches
> / discussion, I'll be an eager tester.
Great. Thanks Craig.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On 07/20/2014 12:55 PM, Peter Geoghegan wrote:
> There is a *really* big
> demand for UPSERT from users, not MERGE, although MERGE is certainly
> useful too.
The inability to efficiently say "Add this unique-keyed row, or if a row
of the same key already exists replace it atomically" is a fundame
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/2014 01:40 AM, Martijn van Oosterhout wrote:
> FWIW, I agree. MERGE is hard enough as it is, but trying to
> guarentee some kind of atomicity makes it nigh on impossible.
> Indeed, after reading what you wrote I think it may well be
> impossib
On Sat, Jul 19, 2014 at 09:55:19PM -0700, Peter Geoghegan wrote:
> At a high level SQL MERGE is quite distinct from UPSERT, in that it is
> a utility command that performs inserts, updates and deletes while
> avoiding race conditions (e.g. unique constraint violations) on a more
> or less best effo
Someone asked me privately why we weren't immediately pursuing SQL
MERGE, as opposed to yet another non-standard variant of UPSERT
(UPSERT is loosely defined here as an insert-or-update DML command
that goes to update based on would-be unique constraint violations,
and does one or the other *atomic
