Re: [patch] libpq one-row-at-a-time API

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

In response to

Responses

Browse pgsql-hackers by date

  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