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

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [patch] libpq one-row-at-a-time API
Date: 2012-07-23 22:07:07
Message-ID: CACMqXCJDoVdzRb0fDEoZkPPvCwnCUMQRBwDtdYfEkpHfcZ3ChQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 24, 2012 at 12:27 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Mon, Jul 23, 2012 at 2:05 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> It seems odd (but maybe ok) that you have to set the single row mode
> on the connection only to have the server reset it whenever you call a
> send function: maybe rename to PQsetResultSingleRowMode?

Server does not reset it, it's purely client-side flag. It is reset
by next PQsend*/PQexec* call. If there are several resultsets
sent by server for one query, they all share the same setting.

I don't think extra-long function names that "describe exactly"
the function behavior are improvement over shorter but inexact
names, as you need to read the docs anyway to know
the real behavior. But its a matter of taste, so it can be
renamed if people want it.

Alternative is to create parallel PQsend* functions that set the flag.
It gets rid of the possibility of any extra activity between PQsend
and PQsetSingleRowMode(). But it seems messy to do that
just for single-row-mode, instead it makes sense to have PQsend*
that takes a flags argument to tune it's behavior. But that
is worth doing only if we have more flags than just one.

> Does PQgetRowData() break the ability to call PQgetvalue() against the
> result as well as other functions like PQgetisnull()? If so, I
> object.

I don't get what are you objecting to. The PQgetRowData()
is called instead of PQgetResult() and it returns zero-row PGresult
for row header and list of PGdataValues that point to actual
data. You call the value functions, they don't crash, but as
the result has zero rows (the data is not copied to it)
they don't do anything useful either.

The whole point of the API is to avoid the unnecessary copying.

You can mix the calls to PQgetRowData() and PQgetResult()
during one resultset, it works fine although does not seem
that useful.

I guess you fear that some code can unexpectedly see
new behavior, and that exactly why the row-callback API
needs to be scrapped - it allowed such possibility.

But with PQsetSingleRowMode and PQgetRowData, the
new behavior is seen only by new code that clearly
expects it, so I don't see what the problem is.

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-07-24 01:22:41 Tab completion for INHERIT and NO INHERIT
Previous Message Merlin Moncure 2012-07-23 21:27:12 Re: [patch] libpq one-row-at-a-time API