From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] libpq one-row-at-a-time API |
Date: | 2012-08-02 05:19:46 |
Message-ID: | 11466.1343884786@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marko Kreen <markokr(at)gmail(dot)com> writes:
> On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So I'm working from the first set of patches in your message
>> <20120721194907(dot)GA28021(at)gmail(dot)com>.
> Great!
Here's an updated draft patch. I've not looked at the docs yet so
this doesn't include that, but I'm reasonably happy with the code
changes now. The main difference from what you had is that I pushed
the creation of the single-row PGresults into pqRowProcessor, so that
they're formed immediately while scanning the input message. That
other method with postponing examination of the rowBuf does not work,
any more than it did with the original patch, because you can't assume
that the network input buffer is going to hold still. For example,
calling PQconsumeInput after parseInput has absorbed a row-data message
but before calling PQgetResult would likely break things.
In principle I suppose we could hack PQconsumeInput enough that it
didn't damage the row buffer while still meeting its API contract of
clearing the read-ready condition on the socket; but it wouldn't be
simple or cheap to do so.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
libpq-single-row-0802.patch | text/x-patch | 48.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Qi Huang | 2012-08-02 09:03:04 | Git diff patch in context diff format |
Previous Message | Marko Kreen | 2012-08-01 19:44:57 | Re: [patch] libpq one-row-at-a-time API |