Skip site navigation (1) Skip section navigation (2)

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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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;

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) {

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


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."
                 -- <>

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-04-27 03:05:02
Subject: Re: [HACKERS] postgres init script things solved
Previous:From: Michael HirohamaDate: 1998-04-27 00:55:54
Subject: Re: retrieving varchar size

pgsql-interfaces by date

Next:From: Sbragion DenisDate: 1998-04-27 08:26:27
Subject: Odbc and Visual Basic
Previous:From: Michael HirohamaDate: 1998-04-27 00:55:54
Subject: Re: retrieving varchar size

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group