Re: Making joins involving ctid work for the benefit of UPSERT

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making joins involving ctid work for the benefit of UPSERT
Date: 2014-07-30 21:17:55
Message-ID: 20140730211755.GA12435@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 28, 2014 at 11:37:07AM -0400, Robert Haas wrote:
> > Yes, but what if you don't see a conflict because it isn't visible to
> > your snapshot, and then you insert, and only then (step 5), presumably
> > with a dirty snapshot, you find a conflict? How does the loop
> > terminate if that brings you back to step 1 with the same MVCC
> > snapshot feeding the update?
>
> Good point. Maybe the syntax should be something like:
>
> UPSERT table (keycol [, keycol] ...) { VALUES (val [, val] ...) [,
> ...] | select_query }

One idea would be to allow UPSERT with constants (single row), and use
CTEs with a SELECT or INSERT/RETURNING for multi-row upserts.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-07-30 21:20:25 Re: Allow GRANT TRIGGER privilege to DROP TRIGGER (Re: Bug ##7716)
Previous Message Peter Geoghegan 2014-07-30 21:06:07 Re: Making joins involving ctid work for the benefit of UPSERT