On Fri, Mar 24, 2023 at 6:39 PM Anton Kirilov <antonvkiri...@gmail.com> wrote: > I have attached a patch that introduces PQsendSyncMessage(), a > function that is equivalent to PQpipelineSync(), except that it does > not flush anything to the server; the user must subsequently call > PQflush() instead. Alternatively, the new function is equivalent to > PQsendFlushRequest(), except that it sends a sync message instead of a > flush request. In addition to reducing the system call overhead of > libpq's pipeline mode, it also makes it easier for the operating > system to send as much of the pipeline as possible in a single TCP (or > lower level protocol) packet when the database is running remotely.
I wonder whether this is the naming that we want. The two names are significantly different. Something like PQpipelineSendSync() would be more similar. I also wonder, really even more, whether it would be better to do something like PQpipelinePutSync(PGconn *conn, bool flush) with PQpipelineSync(conn) just meaning PQpipelinePutSync(conn, true). We're basically using the function name as a Boolean parameter to select the behavior, which is fine if you only have one parameter and it's a Boolean, but it's obviously unworkable if you have say 3 Boolean parameters because you don't want 8 different functions, and what if you need an integer parameter for some reason? So I'd favor exposing a function that is effectively an extended version of PQpipelineSendSync() with an additional Boolean parameter, and that way if for some reason somebody needs to extend it again, they can just make an even more extended version with yet another parameter. That way, all the functionality is always available by calling the newest function, and older ones are still there for older applications. -- Robert Haas EDB: http://www.enterprisedb.com
