From: | Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com> |
---|---|
To: | Boris Kolpackov <boris(at)codesynthesis(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: Pipeline mode and PQpipelineSync() |
Date: | 2021-07-08 13:57:32 |
Message-ID: | 202107081357.xbplnti7szms@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Jul-08, Boris Kolpackov wrote:
> Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-07-08 13:58:35 | Re: SHA-1 FIPS - compliance |
Previous Message | Bruce Momjian | 2021-07-08 13:51:47 | Re: visibility map corruption |