Re: Wrong defeinition of pq_putmessage_noblock since 9.5
От | Michael Paquier |
---|---|
Тема | Re: Wrong defeinition of pq_putmessage_noblock since 9.5 |
Дата | |
Msg-id | CAB7nPqSSNTroRi=zGMDxYa7PzX_VSck6hbHY6eTnBBsfYaah6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Wrong defeinition of pq_putmessage_noblock since 9.5 (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Wrong defeinition of pq_putmessage_noblock since 9.5
|
Список | pgsql-hackers |
On Fri, Jul 29, 2016 at 12:18 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <4313.1469717160@sss.pgh.pa.us> >> Fujii Masao <masao.fujii@gmail.com> writes: >> > 3. Several source comments in pqcomm.c have not been updated. >> > Some comments still use the old function name like pq_putmessage(). >> >> > Attached patch fixes the above issues. >> >> I dunno, this seems like it's doubling down on some extremely poor >> decisions. Why is it that you now have to flip a coin to guess whether >> the prefix is pq_ or socket_ for functions in this module? I would >> rather see that renaming reverted. Yes, I agree with that. I cannot understand the intention behind 2bd9e41 to rename those routines as they are now, so getting them back with pg_ as prefix looks like a good idea to me. > The set of functions in PQcommMethods doesn't seem clean. They > are chosen arbitrarily just so that other pq_* functions used in > parallel workers will work as expected. I suppose that it needs > some refactoring. Any work in this area is likely 10.0 material at this point. > By the way, pq_start/endcopyout() are used only in FE protocols > below 3.0, which had already bacome obsolete as of PG7.4. While > the next dev cycle is for PG10, if there is no particular reason > to support such ancient protocols, removing them would make things > easier and cleaner. Remove support for protocol 2 has been in the air for some time, but that's a separate discussion. If you want to discuss this issue particularly, raising a new thread would be a good idea. -- Michael
В списке pgsql-hackers по дате отправления: