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

On Tue, Jul 24, 2012 at 7:08 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> The PQgetRowData() is unimportant as it just exposes
> the rowBuf to user and thats all.

So to get back to the more interesting PQgetRowData() discussion...

Did you notice that it's up to app to decide whether it calls
PQgetResult() or PQgetRowData() after PQsetSingleRowMode()?
So there is no way for it to get into conflicts with anything.
If libpqtypes keeps using PQgetResult it keeps getting
PGresult. No problem.

The PQgetRowData() is meant for use-cases where PGresult is *not* the
main data structure the app operates on. If the app does dumb
copy out of PGresult as soon as possible, it can move to PGgetRowData().

If app wants do to complex operations with PGresult or just
store it, then it can keep doing it. Nobody forces the use
of PQgetRowData().

Now the about idea about doing more optimized PGresult - one way of doing
it would be to create zero-copy PGresult that points into network
buffer like PGgetRowData() does. But this breaks all expectations
of lifetime rules for PGresult, thus seems like bad idea.

Second way is to optimize the copying step - basically just
do a malloc and 2 or 3 memcopies - for struct, headers
and data. This leaves standalone PGresult around that
behaves as expected. But for apps that don't care about
PGresult it is still unnecessary copy. So even if we
optimize PGresult that way, it still seems worthwhile
to have PGgetRowData() around.

Hm, I think it's possible to rig the test to do dummy
copy of pgresult, thus it's possible to see what kind
of speed is possible.. Will try.

--
marko