Marko Kreen <markokr@gmail.com> writes:
> Now, looking at the problem with some perspective, the solution
> is obvious: when in single-row mode, the PQgetResult() must return
> proper PGresult for that single row. And everything else follows that.
> Such API is implemented in attached patch:
I'm starting to look at this patch now. I think we could drop the
PQgetRowData() API: it complicates matters for little gain that I can
see. The argument for it was to avoid the cost of creating a PGresult
per row, but we're already going to pay the cost of creating a
PGresult in order to return the PGRES_SINGLE_TUPLE status. And as was
pointed out upthread, any per-tuple malloc costs are going to be in
the noise compared to the server-side effort expended to create the
tuple, anyway. The point of this feature is to avoid accumulating the
entire resultset in memory, not to micro-optimize linear-time costs.
Moreover, if the argument for changing 9.2 at this late date is to get
rid of a fragile, breakable API, surely an API that's designed around
returning pointers into the library's network buffer ought to be a
prime target.
And lastly, since the proposed patch for dblink doesn't use
PQgetRowData, there's not even much reason to think that it's
bug-free.
regards, tom lane
