Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tpRS5-005Xnd-82 for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Mar 2025 12:32:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tpRS2-00ECfN-OO for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Mar 2025 12:32:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tpRS2-00ECfF-Eb for pgsql-hackers@lists.postgresql.org; Tue, 04 Mar 2025 12:32:46 +0000 Received: from dverite2024.planet-service.net ([185.16.44.252] helo=mail.verite.pro) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tpRRz-000uNf-36 for pgsql-hackers@postgresql.org; Tue, 04 Mar 2025 12:32:45 +0000 Received: by mail.verite.pro (Postfix, from userid 1000) id 9D3AB2C0D44; Tue, 4 Mar 2025 13:32:41 +0100 (CET) Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: Add Pipelining support in psql From: "Daniel Verite" To: "Anthonin Bonnefoy" Cc: Michael Paquier , Jelte Fennema-Nio , PostgreSQL Hackers In-Reply-To: Date: Tue, 04 Mar 2025 13:32:38 +0100 Message-Id: X-Mailer: Manitou v1.7.3 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Anthonin Bonnefoy wrote: > Another possible option would be to directly send the command without > requiring an additional meta-command, like "SELECT 1 \bind". However, > this would make it more painful to introduce new parameters, plus it > makes the \bind and \bind_named inconsistent as it is normally > required to send the result with a separate meta-command. AFAIU the reason why \bind is required (even when there are no $N parameters in the query) is to trigger the use of the extended query protocol. This pre-dates the pipeline feature. But when in a pipeline, we can't send queries with the simple query protocol anyway, so a possible usability improvement would be to make \bind optional in that case. Concretely it's not possible currently to issue: \startpipeline select 1; it causes the error: "PQsendQuery not allowed in pipeline mode" whereas this sequence does works: \startpipeline \bind select 1; \flushrequest \getresults But if the code triggered the use of the extended query protocol if \bind is in effect *or* a pipeline is active, then the first sequence would just push "select 1" into the pipeline. This would have the advantage that, to submit into a pipeline a pre-existing file with SQL commands separated with ";" you don't have to pre-process it to inject metacommands. Adding a \startpipeline at the beginning and an \endpipeline at the end would be sufficient in the cases that the user does not need the results before the end. The \sendpipeline is not mandatory when ";" can be used to terminate the queries. But it makes it clearer that the script wants specifically to push into a pipeline, and it might accept specific options in the future, whereas obviously ";" cannot. Best regards, --=20 Daniel V=E9rit=E9=20 https://postgresql.verite.pro/