Re: Add PQsendSyncMessage() to libpq
От | Anton Kirilov |
---|---|
Тема | Re: Add PQsendSyncMessage() to libpq |
Дата | |
Msg-id | FA30113C-3DC1-437C-9AA7-192D53E2375E@gmail.com обсуждение исходный текст |
Ответ на | Re: Add PQsendSyncMessage() to libpq (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Add PQsendSyncMessage() to libpq
|
Список | 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 myprevious message? Am I just misunderstanding what the code comment means and how the API is supposed to be used by anychance? Best wishes, Anton Kirilov
В списке pgsql-hackers по дате отправления: