Abhijit Menon-Sen <ams@oryx.com> writes:
> Execute can be told to return no more than n rows of results. If there
> are more rows available, the server returns PortalSuspended and awaits
> another Execute message. The default of 0 imposes no limit.
> Because it's sometimes required to call Execute without Binding values
> again, libpq needs separate bind/execute functions to support this.
I don't really think so. Allowing access to the limited-row-count
version of Execute would fundamentally break the PGresult abstraction,
which thinks of a query result as a monolithic entity.
There has been talk from time to time of developing a new API (possibly
a whole new library?) that would allow streaming access, but I would
strongly urge you not to try to solve that problem at the same time;
if only because there is zero chance of such a patch being accepted
within the 8.0 cycle.
In my mind the existing PQexecPrepared operation is all you need to
support binding and execution of prepared statements. What you should
be concerned with right now is providing an API for Parse + Describe
Statement, to substitute for the existing approach of setting up
statement objects via PQexec("PREPARE foo ...").
regards, tom lane
