Re: Add Pipelining support in psql
Michael Paquier <michael@paquier.xyz>
(My previous message did not reach the lists, so re-sending with some edits.) On Fri, Feb 28, 2025 at 05:31:00PM +0100, Daniel Verite wrote: > The following invocations don't respect the desired output destination > and formats (ignoring them), when a pipeline is active: > > select ... \bind \g filename > select ... \bind \g |program > select ... \bind \g (format=unaligned tuples_only=on) > > Just like for \gx the problem is that in a pipeline, sending the query > is not followed by getting the results, and the output properties > of a query are lost in between. Right. I completely forgot that these options could be applied with a simple \g. With the results being decoupled from the execution, one can argue that the options defined at the moment when the query is sent and executed should be the moment commanding how the result are shaped when retrieving a batch with \getresult during a pipeline. However, this means that we would need to save the set of options from printQueryOpt when running the query depending on the number of results we expect, and reapply them in order of the results expected. We have the APIs to do that, with savePsetInfo() and restorePsetInfo(). Anyway, can we really say that the set of printQueryOpt saved at execution is the correct set to use? It is possible to have the opposite argument and say that we should just apply the printQueryOpt at the moment where \getresult is run. A benefit of that it to keep the loop retrieving results simpler in ExecQueryAndProcessResults(), because we pass down to this call *one* printQueryOpt as "opt". There's of course the simplicity argument that I do like a lot here, but applying the printing options at the time of \getresult feels also more natural to me. FWIW, I agree that HEAD is unbalanced with its handling of \gx, so we could do one of the following two things: 1) Ignore any formatting options given to \g, but also allow \gx to run, documenting that during a pipeline the formatting options are ignored, and that the set of options defined when doing a \getresult is the only thing that matters. 2) Invent a new meta-command (suggested by Daniel Verite off-list, and not published to the lists because I don't know how to do a reply-all), like a \send, a \push, forbiding entirely \gx and \g when in a pipeline. If we were to integrate options into this new meta-command, a split with \g would make an integration easier to think about. One name suggestion I can come up is \sendpipeline. I'd consider option 2, based on Daniel's concerns. One line I'm going to draw here is that we should not go down to manipulations of printQueryOpt while retrieving batch of results depending on the style of output that was defined when sending a query in a pipeline. Anthonin, as the primary author, any thoughts? -- Michael
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
psql: Fix assertion failures with pipeline mode
- 3631612eae9c 18.0 landed
-
psql: Rework TAP routine psql_fails_like() to define WAL sender context
- 0ff95e0a5be1 18.0 landed
-
psql: Split extended query protocol meta-commands in --help=commands
- 78231baaf967 18.0 landed
-
psql: Improve descriptions of \\flush[request] in --help
- 5743d122fcf3 18.0 landed
-
psql: Fix incorrect status code returned by \getresults
- 5ee7bd944ee8 18.0 landed
-
psql: Allow queries terminated by semicolons while in pipeline mode
- 2cce0fe440fb 18.0 landed
-
psql: Add \sendpipeline to send query buffers while in a pipeline
- 17caf6644546 18.0 landed
-
psql: Fix memory leak with \gx used within a pipeline
- 54d23601b978 18.0 landed
-
psql: Add pipeline status to prompt and some state variables
- 3ce357584e79 18.0 landed
-
Add more tests for utility commands in pipelines
- a4e986ef5a46 18.0 landed
-
psql: Add support for pipelines
- 41625ab8ea3d 18.0 landed
-
Add braces for if block with large comment in psql's common.c
- 40af897eb777 18.0 landed