From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199804262341.TAA07189@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Sun, 26 Apr 1998 19:41:33 -0400 (EDT)
Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
In-Reply-To: <1360.893632408@sss.pgh.pa.us> from "Tom Lane" at Apr 26,
	98 07:13:28 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

OK, you just need to remember to throw away any un-called-for results if
they do another PQexec without retrieving all the results returned by
the backend.

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

Yep.


> Well, we can settle for having PQendcopy return 0 or 1 as it does now.
> It's not quite as clean as having it return a real PGresult, but it's
> probably not worth breaking existing apps just to improve the
> consistency of the API.  It'd still be possible to queue up subsequent
> commands' results (if any) in the result queue.

OK.

> > Again, if we clearly document the change, we are far enough from 6.4
> > that perl and other people will handle the change by the time 6.4 is
> > released.  Changes the affect user apps is more difficult.
> 
> I have mixed feelings about this particular item.  It would make the
> protocol more robust, but it's not clear that the gain is worth the
> risk of breaking any existing apps.  I'm willing to drop it if no one
> else is excited about it.

It's up to you.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)