Re: BUG #13846: INSERT ON CONFLICT consumessequencersonconflicts

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Paul <paul(at)salesintel(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13846: INSERT ON CONFLICT consumessequencersonconflicts
Date: 2016-05-06 19:10:22
Message-ID: CAM3SWZTZZ4hvPYY=cM3QUMsdUP7NML7S=L=u=EyLj9yyeHjedw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, May 6, 2016 at 12:02 PM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> To solve this situation it is likely that some form of "UPDATE ON MISSING
> INSERT" would need to be designed. The insert portion would specify
> "DEFAULT" for sequence columns and would execute nextval() only if the ON
> MISSING portion is executed.

That's unworkable, at least without accepting a bunch of new
edge-cases, like having the insert then have a duplicate violation
involving a value that was determined to not exist in the first phase.
IOW, it's unworkable to do an insert on the basis of an *absence* of
something in an index or in a table (and not get those edge-cases).
Doing so on the basis of the *presence* of a value (i.e. INSERT ... ON
CONFLICT DO UPDATE as implemented) lets the implementation clamp down
on race conditions enough to provide those useful user-visible
guarantees about getting 1 of 2 possible outcomes.

There are multiple definitions of a value "existing" here that are in
tension here. It's rather complicated.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2016-05-06 19:15:18 Re: BUG #13846: INSERT ON CONFLICT consumessequencersonconflicts
Previous Message David G. Johnston 2016-05-06 19:02:33 Re: BUG #13846: INSERT ON CONFLICT consumessequencersonconflicts