Re: [HACKERS] Re: [INTERFACES] retrieving varchar size

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > My idea is to make a PQexecv() just like PQexec, except it returns an
> > array of results, with the end of the array terminated with a NULL,
> > [ as opposed to my idea of returning PGresults one at a time ]
>
> Hmm. I think the one-at-a-time approach is probably better, mainly
> because it doesn't require libpq to have generated all the PGresult
> objects before it can return the first one.
>
> Here is an example in which the array approach doesn't work very well:
>
> QUERY: copy stdin to relation ; select * from relation
>
> What we want is for the application to receive a PGRES_COPY_IN result,
> perform the data transfer, call PQendcopy, and then receive a PGresult
> for the select.
>
> I don't see any way to make this work if the library has to give back
> an array of results right off the bat. With the other method, PQendcopy
> will read the select command's output and stuff it into the (hidden)
> result queue. Then when the application calls PQnextResult, presto,
> there it is. Correct logic for an application that submits multi-
> command query strings would be something like
>
> result = PQexec(conn, query);
>
> while (result) {
> switch (PQresultStatus(result)) {
> ...
> case PGRES_COPY_IN:
> // ... copy data here ...
> if (PQendcopy(conn))
> reportError();
> break;
> ...
> }
>
> PQclear(result);
> result = PQnextResult(conn);
> }
>
>
> Another thought: we might consider making PQexec return as soon as it's
> received the first query result, thereby allowing the frontend to
> overlap its processing of this result with the backend's processing of
> the rest of the query string. Then, PQnextResult would actually read a
> new result (or the "I'm done" message), rather than just return a result
> that had already been stored. I wasn't originally thinking of
> implementing it that way, but it seems like a mighty attractive idea.
> No way to do it if we return results as an array.

Or we might even make PQexec return as soon as the query is sent and parsed.
It could ruturn a handle to the query that could be used to get results later.
This is pretty much exactly in line with the way the Perl DBI stuff works and
I think also odbc.

queryhandle = PQexec(conn, querystring);

while (result = PQgetresult(queryhandle)) {
do stuff with result;
PQclear(result);
}

This protocol allows for multiple results per query, and asynchronous operation
before getting the result.

Perhaps a polling form might be added too:

queryhandle = PQexec(conn, querystring);

while (1) {
handle_user_interface_events();

if (PQready(queryhandle)) {
result = PQgetresult(queryhandle);
if (result == NULL)
break;
do stuff with result;
PQclear(result);
}
}

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"(Windows NT) version 5.0 will build on a proven system architecture
and incorporate tens of thousands of bug fixes from version 4.0."
-- <http://www.microsoft.com/y2k.asp?A=7&B=5>