Skip site navigation (1) Skip section navigation (2)

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-24 16:08:28
Message-ID: (view raw, whole thread or download thread mbox)
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@
>, 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?


In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2012-07-24 16:25:41
Subject: Re: [patch] libpq one-row-at-a-time API
Previous:From: Merlin MoncureDate: 2012-07-24 15:56:40
Subject: Re: [patch] libpq one-row-at-a-time API

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group