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

At Fri, 29 Jul 2016 11:58:04 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <14846.1469807884@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > The many of the socket_* functions are required to be replaced
> > with mq_* functions for backgroud workers. So reverting the names
> > of socket_* functions should be accompanied by the need to, for
> > example, changing their callers to use them explicitly via
> > PqCommMethods, not hiding with macros, or renaming current pq_*
> > macros to, say, pqi_. (it stands for PQ-Indirect as a tentative)
> > I'm not confident on the new prefix since I'm not sure that what
> > the 'pq' stands for. (Postgres Query?)
> 
> Hmm.  Of course the problem with this approach is that we end up touching
> a whole bunch of call sites, which sort of negates the point of having
> installed a compatibility macro layer.
> 
> [ spends awhile longer looking around at this code ]
> 
> Maybe the real problem here is that the abstraction layer is so incomplete
> and apparently haphazard, so that it's not very obvious where you should
> use a pq_xxx name and where you should refer to socket_xxx.

Yes, 'haphazard' is the word I was seeking for.

> For some of
> the functions in pqcomm.c, such as internal_flush, it's impossible to tell
> which side of the abstraction boundary they're supposed to be on.
> (I suspect that that particular function has simply been ignored on the
> undocumented assumption that a bgworker could never call it, but that's
> the kind of half-baked work that I don't find acceptable.)
> 
> I think the core work that needs to be done here is to clearly identify
> each function in pqcomm.c as either above or below the PqCommMethods
> abstraction boundary.  Maybe we should split one set or the other out
> to a new source file.  In any case, the naming convention ought to
> reflect that hierarchy.

Agreed. I'm not sure if there's a clean boundary, though.

> I withdraw the idea that we should try to revert all these functions back
> to their old names, since that would obscure the layering distinction
> between socket-specific and general-usage functions.  I now think that
> the problem is that that distinction hasn't been drawn sharply enough.
> 
> > 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.
> 
> Yeah, exactly.
> 
> > Any work in this area is likely 10.0 material at this point.
> 
> I'm not really happy with that, since refactoring it again will create
> back-patch hazards.  But I see that a lot of the mess here was created
> in 9.5, which means we're probably stuck with back-patch hazards anyway.

I think we have an alternative not to backpatch that
refactoring. 9.5 works with it happily and won't get further
improovement in this area.

>             regards, tom lane
> 
> PS: "PQ" comes from PostQUEL, I believe.

Thanks, I've learned something new:)

https://en.wikipedia.org/wiki/QUEL_query_languages

> range of E is EMPLOYEE
> retrieve into W
> (COMP = E.Salary / (E.Age - 18))
> where E.Name = "Jones"

It looks more methematical or programming-language-like to me
than SQL.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center