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

On Wed, Jul 25, 2012 at 12:35 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Jul 24, 2012 at 3:52 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> I would prefer to have PQsetSingleRowMode() over new flavor of PQsend.
>
> To consolidate my argument above: since you're throwing PQgetResult in
> the main iteration loop you're potentially walling yourself off from
> one important optimization: not copying the result at all and reusing
> the old one; that's going to produce the fastest possible code since
> you're recovering all the attribute structures that have already been
> set up unless you're willing to do the following:

I am not forgetting such optimization, I've already implemented it:
it's called PQgetRowData(). Main reason why it works, and so simply,
is that it does not try to give you PGresult.

PGresult carries various historical assumptions:
- Fully user-controlled lifetime.
- Zero-terminated strings.
- Aligned binary values.

Breaking them all does not seem like a good idea.

Trying to make them work with zero-copy seems
not worth the pain.

And if you are ready to introduce new accessor functions,
why care about PGresult at all? Why not give user
PQgetRowData()?

Btw, PQgetRowData() and any other potential zero-copy API
is not incompatible with both slow PQgetResult() or optimized
PQgetResult().

So if we give only PQgetResult() in 9.2, I do not see that we
are locked out from any interesting optimizations.

--
marko