Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YvFun-0007qz-RO for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2015 02:08:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YvFun-0004tL-Bz for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2015 02:08:53 +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 1YvFul-0004tE-Rq for pgsql-hackers@postgresql.org; Thu, 21 May 2015 02:08:52 +0000 Received: from mail-lb0-f181.google.com ([209.85.217.181]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YvFuj-0001Cd-2B for pgsql-hackers@postgresql.org; Thu, 21 May 2015 02:08:50 +0000 Received: by lbbqq2 with SMTP id qq2so7679562lbb.3 for ; Wed, 20 May 2015 19:08:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cLhqjbBHm5hRua707MfYHg8/Q/uItsZnJS+12s+oRKE=; b=koMStT5yG6x7t7iR8UXkpFKV3FRmvl4cwuhriDZfZrawJKc7j6a//V1N7MsjLBGBKf zCY13ECb6oXmTQZVlQcByzi685WTpWOkxFWTUwVV2NSQMJx7xBNgVlYzFDEAbuoWizeg tZ5UWYkUlOjocioO1R38Va34JASGeHR5Ixze78qNAMZoyIh6z/5Wh7jHEmekQXnBE8/d 9lrjUxlvnto3uUDYX/Rn/qF1mqxtPxR1xALNHD0HHC8Q6GKafw8YST79wncDnsX32x2C owAzFsV53Mgq26uEWkEJEhNjQjNNEWE1XQA3nnAO/XeS8Ql00B+ez8V9AblIwlBd6aRJ WgZQ== X-Gm-Message-State: ALoCoQncKNefXy7cOwEjK5QRWvNtYWuJptzudzwOPv1XbNANfRan1QD1AE2VP5FFrAoju+woY/JT MIME-Version: 1.0 X-Received: by 10.152.164.233 with SMTP id yt9mr281057lab.58.1432174126779; Wed, 20 May 2015 19:08:46 -0700 (PDT) Received: by 10.114.57.132 with HTTP; Wed, 20 May 2015 19:08:46 -0700 (PDT) In-Reply-To: <10660.1432171328@sss.pgh.pa.us> References: <20150520215816.GI5885@postgresql.org> <20150520220911.GK5885@postgresql.org> <20150521011229.GX27868@alap3.anarazel.de> <10660.1432171328@sss.pgh.pa.us> Date: Wed, 20 May 2015 19:08:46 -0700 Message-ID: Subject: Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE. From: Peter Geoghegan To: Tom Lane Cc: Andres Freund , Alvaro Herrera , Pg Hackers Content-Type: text/plain; charset=UTF-8 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 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? > I think we should fix this by ripping out the variant tag, not trying > to propagate it everywhere it would need to go. Cute ideas are not > the same as good ideas. I don't feel particularly strongly about it one way or the other. The way the command tag reports number of rows affected beside the INSERT tag in psql is relevant. If some of those rows were actually updated, that could mislead. I'm not saying that it outweighs your concern, but it was the reason for inventing a variant tag, and it is a consideration. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers