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

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

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Marko Kreen <markokr(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 15:18:41
Message-ID: CAHyXU0ysQ0akWms2XiJ6YbOaGpxW5U24Rt5QFtYDpBwQj0Qy8Q@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.  For
example, maybe PQsetSingleRowMode maybe should return a result object?

merlin

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-07-24 15:49:17
Subject: Re: [patch] libpq one-row-at-a-time API
Previous:From: Alvaro HerreraDate: 2012-07-24 15:08:09
Subject: Re: isolation check takes a long time

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