From: | Anton Kirilov <antonvkirilov(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add PQsendSyncMessage() to libpq |
Date: | 2023-05-04 09:21:56 |
Message-ID: | FA30113C-3DC1-437C-9AA7-192D53E2375E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
> On 3 May 2023, at 11:03, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2023-May-02, Robert Haas wrote:
>
>> On Mon, May 1, 2023 at 8:42 PM Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-05-04 10:36:42 | Re: Add PQsendSyncMessage() to libpq |
Previous Message | Richard Guo | 2023-05-04 08:07:10 | Introduce join_info_array for direct lookups of SpecialJoinInfo by ojrelid |