Re: Wrong defeinition of pq_putmessage_noblock since 9.5 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Wrong defeinition of pq_putmessage_noblock since 9.5
Date
Msg-id CAB7nPqSSNTroRi=zGMDxYa7PzX_VSck6hbHY6eTnBBsfYaah6A@mail.gmail.com
Whole thread Raw
In response to Re: Wrong defeinition of pq_putmessage_noblock since 9.5  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Wrong defeinition of pq_putmessage_noblock since 9.5
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: old_snapshot_threshold allows heap:toast disagreement
Next
From: Etsuro Fujita
Date:
Subject: Re: Oddity in EXPLAIN for foreign/custom join pushdown plans