Re: Pipeline mode and PQpipelineSync() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Pipeline mode and PQpipelineSync()
Date
Msg-id 202107081357.xbplnti7szms@alvherre.pgsql
Whole thread Raw
In response to Re: Pipeline mode and PQpipelineSync()  (Boris Kolpackov <boris@codesynthesis.com>)
Responses Re: Pipeline mode and PQpipelineSync()  (Boris Kolpackov <boris@codesynthesis.com>)
List pgsql-hackers
On 2021-Jul-08, Boris Kolpackov wrote:

> Alvaro Herrera <alvaro.herrera@2ndquadrant.com> writes:
> 
> > Hmm ... aren't you trying to read more results than you sent queries?
> 
> Hm, but should I be able to? Or, to put another way, should PQisBusy()
> indicate there is a result available without me sending a query for it?
> That sounds very counter-intuitive to me.

That seems a fair complaint, but I think PQisBusy is doing the right
thing per its charter.  It is documented as "would PQgetResult block?"
and it is returning correctly that PQgetResult would not block in that
situation, because no queries are pending.  I think we would regret
changing PQisBusy in the way you suggest.

I think your expectation is that we would have an entry point for easy
iteration; a way to say "if there's a result set to be had, can I have
it please, otherwise I'm done iterating".  That seems a reasonable ask,
but PQisBusy is not that.  Maybe it would be PQisResultPending() or
something like that.  I again have to ask the RMT what do they think of
adding such a thing to libpq this late in the cycle.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: visibility map corruption
Next
From: Bruce Momjian
Date:
Subject: Re: SHA-1 FIPS - compliance