Re: Add PQsendSyncMessage() to libpq - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Add PQsendSyncMessage() to libpq
Date
Msg-id CA+TgmobOhwZOBKB7DMytD6SXasX4D9O4ehOG7RLHkP=sd0J7Ww@mail.gmail.com
Whole thread Raw
In response to Add PQsendSyncMessage() to libpq  (Anton Kirilov <antonvkirilov@gmail.com>)
Responses Re: Add PQsendSyncMessage() to libpq  (Anton Kirilov <antonvkirilov@gmail.com>)
List pgsql-hackers
On Fri, Mar 24, 2023 at 6:39 PM Anton Kirilov <antonvkirilov@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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Support logical replication of DDLs
Next
From: "Regina Obe"
Date:
Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames