From: Bruce Momjian <maillist@candle.pha.pa.us>
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Date: Sun, 26 Apr 1998 19:41:33 -0400 (EDT)
Message-ID: <199804262341.TAA07189@candle.pha.pa.us> (raw)
In-Reply-To: <1360.893632408@sss.pgh.pa.us>
>
> 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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: maillist@candle.pha.pa.us, tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
In-Reply-To: <199804262341.TAA07189@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox