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-24 16:08:28 |
Message-ID: | CACMqXC+WgZC5KuYCvbJEJTahntp=Mf+tyzEuAYw+-5GdkmhLjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 24, 2012 at 6:18 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Mon, Jul 23, 2012 at 5:07 PM, Marko Kreen <markokr(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-07-24 16:25:41 | Re: [patch] libpq one-row-at-a-time API |
Previous Message | Merlin Moncure | 2012-07-24 15:56:40 | Re: [patch] libpq one-row-at-a-time API |