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

On Tue, Jul 24, 2012 at 6:18 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Mon, Jul 23, 2012 at 5:07 PM, Marko Kreen <markokr@gmail.com> wrote:
>>> 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.
>
> Well, for one, it breaks libpqtypes (see line 171@
> http://libpqtypes.esilo.com/browse_source.html?file=exec.c), or at
> least makes it unable to use the row-processing mode.   libpqtypes
> wraps the libpq getter functions and exposes a richer api using only
> the result object.  When writing libpqtypes we went through great
> pains to keep access to server side data through the existing result
> API.  Note, I'm not arguing that compatibility with libpqtypes is a
> desired objective, but the wrapping model that it uses is pretty
> reasonably going to be used by other code -- the awkwardness there
> should be a red flag of sorts.
>
> I'm arguing that *all* data getting must continue to do so through the
> result object, and bypassing the result to get at data is breaking the
> result abstraction in the libpq api.  I bet you can still maintain
> data access through result object while avoiding extra copies.

Well, the main problem this week is whether we should
apply PQsetSingleRowMode() from single-row-mode1
or from single-row-mode2 branch?

The PQgetRowData() is unimportant as it just exposes
the rowBuf to user and thats all.

Do you have opinion about that?

>  For example, maybe PQsetSingleRowMode maybe should return a result object?

What do you mean by that?  And have you though about both
sync and async usage patterns?

-- 
marko