|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Fujii Masao <masao(dot)fujii(at)gmail(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Non-blocking communication between a frontend and a backend (pqcomm)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> Are you planning to update this patch based on Martin's review?
> Sure. Attached is an updated patch.
I looked at this patch. I don't see how we can consider accepting it
by itself. It adds a bunch of code that is not used anywhere and hence
can't be tested, in service of goals explained nowhere, but presumably
part of some other patch that hasn't been reviewed and might or might
not get accepted when it is presented. The only thing that's really
clear is that it pokes holes in the abstraction (such as it is)
presented by pqcomm.c.
The reason I want to see the calling code is that I doubt this is a very
useful API extension as-is. I can see the point of probing to see if
any more bytes are available, but it's not clear that there is a reason
to collect only part of a message once the client has sent one. I am
also thinking that if you do need the ability to get control back
without blocking on the socket, you probably will need that for writes
as well as reads; and this patch doesn't cover the write case.
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.
regards, tom lane
|Next Message||Andrew Dunstan||2009-07-24 23:25:51||Re: COPY WITH CSV FORCE QUOTE * -- REVIEW|
|Previous Message||David E. Wheeler||2009-07-24 22:47:39||Re: When is a record NULL?|