From: | dg(at)illustra(dot)com (David Gould) |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | maillist(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: [INTERFACES] retrieving varchar size |
Date: | 1998-04-27 01:46:42 |
Message-ID: | 9804270146.AA14710@hawk.illustra.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
> 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>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-04-27 03:05:02 | Re: [HACKERS] postgres init script things solved |
Previous Message | Michael Hirohama | 1998-04-27 00:55:54 | Re: retrieving varchar size |
From | Date | Subject | |
---|---|---|---|
Next Message | Sbragion Denis | 1998-04-27 08:26:27 | Odbc and Visual Basic |
Previous Message | Michael Hirohama | 1998-04-27 00:55:54 | Re: retrieving varchar size |