Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YoCFv-0006be-2m for pgsql-hackers@arkaria.postgresql.org; Fri, 01 May 2015 14:49:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YoCFu-0002nN-Eg for pgsql-hackers@arkaria.postgresql.org; Fri, 01 May 2015 14:49:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YoCFs-0002kv-Fg for pgsql-hackers@postgresql.org; Fri, 01 May 2015 14:49:28 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1YoCFq-0002eq-34 for pgsql-hackers@postgresql.org; Fri, 01 May 2015 14:49:27 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id 36FAD860001; Fri, 1 May 2015 16:49:25 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p54895C9D.dip0.t-ipconnect.de [84.137.92.157]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 11C86860001; Fri, 1 May 2015 16:49:22 +0200 (CEST) Received: by anarazel.de (Postfix, from userid 1000) id 89405100C30; Fri, 1 May 2015 16:49:21 +0200 (CEST) Date: Fri, 1 May 2015 16:49:21 +0200 From: Andres Freund To: Robert Haas Cc: Peter Geoghegan , hlinnaka , Jeff Janes , Stephen Frost , Dean Rasheed , Bruce Momjian , Pg Hackers Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 Message-ID: <20150501144921.GH22649@awork2.anarazel.de> References: <20150501135800.GC22649@awork2.anarazel.de> <20150501141052.GE22649@awork2.anarazel.de> <20150501142403.GG22649@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2015-05-01 10:39:35 -0400, Robert Haas wrote: > On Fri, May 1, 2015 at 10:24 AM, Andres Freund wrote: > > The BEFORE UPDATE would catch things in this case. > > OK. In that case, I'm a lot less sure what the right decision is. It > seems weird for both the BEFORE INSERT and BEFORE UPDATE triggers to > get a crack at the same tuple, so your way might be better after all. > But on the other hand, the BEFORE INSERT trigger might have had side > effects, so we can't just pretend it didn't happen. Well, I think it's pretty unavoidable to fire both. On that part I think were pretty lengthy discussions a year or so back. > One idea is to decide that an INSERT with an ON CONFLICT UPDATE > handler is still an INSERT. Period. So the INSERT triggers run, the > UPDATE triggers don't, and that's it. I think that'd be much worse. One question, that I was wondering about earlier, that also might influence this discussion, is what happens if you change the key we're using for resolution during either the BEFORE trigger or the ON CONFLICT ... SET. Right now the conflict will be on the version *after* the BEFORE INSERT, which I think think is the only reasonable option. And if you're mad enough to change the key in the ON CONFLICT ... SET ... you'll possibly get conflicts. I was, over IM, arguing for that to be forbidden to protect users against themselves, but Heikki said people might e.g. want to set a column in a key to NULL in that case. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers