Re: Add PQsendSyncMessage() to libpq

Anton Kirilov <antonvkirilov@gmail.com>

From: Anton Kirilov <antonvkirilov@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2023-05-04T09:21:56Z
Lists: pgsql-hackers
Hello,

> On 3 May 2023, at 11:03, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> On 2023-May-02, Robert Haas wrote:
> 
>> On Mon, May 1, 2023 at 8:42 PM Michael Paquier <michael@paquier.xyz> wrote:
>>> Another thing that may matter in terms of extensibility?  Would a
>>> boolean argument really be the best design?  Could it be better to
>>> have instead one API with a bits32 and some flags controlling its
>>> internals?
>> 
>> I wondered that, too. If we never add any more Boolean parameters to
>> this function then that would end up a waste, but maybe we will and
>> then it will be genius. Not sure what's best.
> 
> I agree that adding a flag is the way to go, since it improve chances
> that we won't end up with ten different functions in case we decide to
> have eight other behaviors.  One more function and we're done.  And
> while I can't think of any use for a future flag, we (I) already didn't
> of this one either, so let's not make the same mistake.

Thank you all for the feedback! Do you have any thoughts on the other issue with PQpipelineSync() I have mentioned in my previous message? Am I just misunderstanding what the code comment means and how the API is supposed to be used by any chance?

Best wishes,
Anton Kirilov



Commits

  1. Remove some comments related to pqPipelineSync() and PQsendPipelineSync()

  2. libpq: Add PQsendPipelineSync()

  3. Fix stop condition for dumping GRANT commands