Re: Non-blocking communication between a frontend and a backend (pqcomm)

On Sat, Jul 25, 2009 at 11:41 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think you should just submit this with the code that uses it, so we
>>> can evaluate whether the overall concept is a good one or not.
>
>> This was split out from Synch Rep based on my suggestion to submit
>> separately any parts that are separately committable, but that doesn't
>> seem to be the case given your comments here.  I guess the question is
>> whether it's necessary and/or desirable to put in the effort to create
>> a general-purpose facility, or whether we should be satisfied with the
>> minimum level of infrastructure necessary to support Synch Rep and
>> just incorporate it into that patch.
>
> General-purpose facility *for what*?  It's impossible to evaluate the
> code without a definition of the purpose behind it.
>
> What I actually think should come first is a spec for the client
> protocol this is intended to support.  It's not apparent to me at
> the moment why the backend should need non-blocking read at all.

[ reads the patch ]

OK, I agree, I can't see what this is for either from the code that is
here. I think I read a little more meaning into the title of the
patch than was actually there. It seems like the appropriate thing to
do is mark this returned with feedback, so I'm going to go do that.

...Robert