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

From Kyotaro HORIGUCHI
Subject Re: Wrong defeinition of pq_putmessage_noblock since 9.5
Date
Msg-id 20160729.121832.200301649.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Wrong defeinition of pq_putmessage_noblock since 9.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Wrong defeinition of pq_putmessage_noblock since 9.5  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.

The set of functions in PQcommMethods doesn't seem clean. They
are choosed arbitrary just so that other pq_* functions used in
parallel workers will work as expected. I suppose that it needs
some refactoring.

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 acient protocols, removing them would make things
easier and cleaner.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: old_snapshot_threshold allows heap:toast disagreement
Next
From: Andres Freund
Date:
Subject: Re: old_snapshot_threshold allows heap:toast disagreement