Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDAkZ-0006tt-Lk for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Feb 2021 18:43:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lDAkY-0005UO-IU for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Feb 2021 18:43:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDAkY-0005UG-B9 for pgsql-hackers@lists.postgresql.org; Fri, 19 Feb 2021 18:43:34 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDAkV-0003Sm-PU for pgsql-hackers@postgresql.org; Fri, 19 Feb 2021 18:43:33 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 5A11E18A; Fri, 19 Feb 2021 13:43:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 19 Feb 2021 13:43:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=bdUpuZ0SSeHW+YF6jnFko99yrN5UewFycXPqB/dT9wc=; b=kcr9yQrz q3HIDejUEGUG6eUGkKgwCeaD61sC+zgQWN0yU/0YTFGE/zfEuRRvNf+CXKFhA2B9 IFUK9FjeF8T636RaJGqcT2nW13YS+LKMZ8xJ8YoqZv7SST0U4YYDVSXQhhbRYRlU 15CawyiuxK1X6ggR7y5zXOsr4wJaB0FaOAmcbt2iN/RXXWK4PSs07bgIGwFtBmoC TCxJlc8w5A5uXs5MMifzsYLLQMQLdkiTL+NMo9SN5daE705bEHiLJdV5oIffSjH8 BZbklJ8jM/DAaXeaVPf2KrUX9cdU3Kbg7QkNEDk6du4OJk5PYXAoVnNbKFchYx5U 0/XJfZUU+LKcTw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjeeigdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepueffhfejieeuueffgedvudekgeeltdeviedvieeufeei ieevgfetheeufeethedvnecukfhppeduledtrdelhedrudelrddujeejnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 18CFF24005D; Fri, 19 Feb 2021 13:43:26 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id A0B8B2A39D1; Fri, 19 Feb 2021 15:43:23 -0300 (-03) Date: Fri, 19 Feb 2021 15:43:23 -0300 From: Alvaro Herrera To: Zhihong Yu Cc: "David G. Johnston" , Daniel Verite , Matthieu Garrigues , Michael Paquier , Dave Cramer , PostgreSQL-development , Craig Ringer , Vaishnavi Prabakaran , Andres Freund , Michael Paquier , Claudio Freire , Heikki Linnakangas Subject: Re: PATCH: Batch/pipelining support for libpq Message-ID: <20210219184323.GA5038@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Jan-21, Zhihong Yu wrote: > It seems '\\gset or \\aset is not ' would correspond to the check more > closely. > > + if (my_command->argc != 1) > + syntax_error(source, lineno, my_command->first_line, > my_command->argv[0], > > It is possible that my_command->argc == 0 (where my_command->argv[0] > shouldn't be accessed) ? No -- process_backslash_command reads the word and sets it as argv[0]. > + appendPQExpBufferStr(&conn->errorMessage, > + libpq_gettext("cannot queue commands > during COPY\n")); > + return false; > + break; > > Is the break necessary ? Similar comment for pqBatchProcessQueue(). Not necessary. I removed them. > +int > +PQexitBatchMode(PGconn *conn) > > Since either 0 or 1 is returned, maybe change the return type to bool. I was kinda tempted to do that, but in reality a lot of libpq's API is defined like that -- to return 0 (failure)/1 (success) as ints, not bools. For example see PQsendQuery(). I'm not inclined to do different for these new functions. (One curious case is PQsetvalue, which returns int, and is documented as "returns zero for failure" and then uses "return false"). > Also, the function operates on PGconn - should the function be static > (pqBatchProcessQueue is) ? I don't understand this suggestion. How would an application call it, if we make it static? Thanks -- Álvaro Herrera Valdivia, Chile "Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en La Feria de las Tinieblas, R. Bradbury)