Marko Kreen <mark...@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. >> >> * PQgetRowData(): can be called instead PQgetResult() to get raw row data >> in buffer, for more efficient processing. This is optional feature >> that provides the original row-callback promise of avoiding unnecessary >> row data copy. >> >> * Although PQgetRowData() makes callback API unnecessary, it is still >> fully compatible with it - the callback should not see any difference >> whether the resultset is processed in single-row mode or >> old single-PGresult mode. Unless it wants to - it can check >> PGRES_TUPLES_OK vs. PGRES_SINGLE_TUPLE.
I guess this raises the question of whether we ought to revert the row-callback patch entirely and support only this approach. IMO it is (barely) not too late to do that for 9.2, if we want to. If we don't want to, then this is just another new feature and should be considered for 9.3. What I like about this is the greatly simpler and harder-to-misuse API. The only arguable drawback is that there's still at least one malloc/free cycle per tuple, imposed by the creation of a PGresult for each one, whereas the callback approach avoids that. But worrying about that could be considered to be vast overoptimization; the backend has certainly spent a lot more overhead than that generating the tuple. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers