Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YvPnw-0007Gt-OR for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2015 12:42:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YvPnv-0003yx-Up for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2015 12:42:27 +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 1YvPnu-0003yr-Jx for pgsql-hackers@postgresql.org; Thu, 21 May 2015 12:42:26 +0000 Received: from mail-pd0-x236.google.com ([2607:f8b0:400e:c02::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YvPnr-0004rS-VP for pgsql-hackers@postgresql.org; Thu, 21 May 2015 12:42:25 +0000 Received: by pdfh10 with SMTP id h10so107044033pdf.3 for ; Thu, 21 May 2015 05:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P/9UAJbkoM4tJKBdxdrLTKKa27YyjlWeefHn5D/klwE=; b=cx+FxTHpbflzAYW0X7NK8ORipVY63DuLqpv2luJxaxG2kcW1KDAGTj7MvCSawgYkNP NrYHtHKAtiz7wYhMSvVRgEgKPv7BIY1v8Fl6CTzEMiqRFi6YFZXxbAFHn+6KUesS5P86 CsgkzHqQNVKTRMtsOJcjuQDaQGo78Er/pFZlIjuo8d3Q3nERu7NEZFLDw8/JawnMXQy6 V52zo/RaIFYCH0Mloxl4bbLH/SyVy7HRGCWK4p1dhbGe2IZcMgkvhjrgbtlEkGRs87XW jR40/n5uomXRl73PlfP/XUyHP888wiWLFwqMB/kJEOooY2tUF2NmchNlflqp+xu2b32f RTDA== X-Received: by 10.68.205.33 with SMTP id ld1mr5434656pbc.22.1432212142567; Thu, 21 May 2015 05:42:22 -0700 (PDT) Received: from [192.168.1.99] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by mx.google.com with ESMTPSA id bs4sm19226717pdb.21.2015.05.21.05.42.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 05:42:21 -0700 (PDT) Message-ID: <555DD2A9.202@iki.fi> Date: Thu, 21 May 2015 15:42:17 +0300 From: Heikki Linnakangas Reply-To: hlinnaka@iki.fi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Peter Geoghegan , Tom Lane CC: Andres Freund , Alvaro Herrera , Pg Hackers Subject: Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE. References: <20150520215816.GI5885@postgresql.org> <20150520220911.GK5885@postgresql.org> <20150521011229.GX27868@alap3.anarazel.de> <10660.1432171328@sss.pgh.pa.us> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 05/21/2015 05:08 AM, Peter Geoghegan wrote: > On Wed, May 20, 2015 at 6:22 PM, Tom Lane wrote: >> I am not really sure that it was a good idea to invent >> this command tag. In fact, I'm pretty sure it was a *bad* idea --- >> what will happen if we ever create a statement actually named UPSERT? > > Why would we invent a statement actually named UPSERT? And if we did, surely it would do some sort of an upsert operation, we could use the UPSERT command tag for that too. That said, I'm also not sure adding the UPSERT command tag is worth the trouble. I'm OK with ripping it out. The row count returned in the command tag is handy in the simple cases, but it gets complicated as soon as you have rules or triggers, so you can't rely much on it anyway. So as long as we document what the count means for an INSERT ... ON CONFLICT, it should be OK to use the INSERT tag. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers