Re: [HACKERS] Re: [INTERFACES] retrieving varchar size - Mailing list pgsql-interfaces

> Bruce Momjian <maillist@candle.pha.pa.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@illustra.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>