Hello Peter,
>> I'd go further and suggest that there shouldn't be a variable
>> controlling this. All results that come in should be processed, period.
>
> I agree with that.
I kind of agree as well, but I was pretty sure that someone would complain
if the current behavior was changed.
Should I produce a patch where the behavior is not an option, or turn the
option on by default, or just keep it like that for the time being?
>> It's not just about \; If the ability of CALL to produce multiple
>> resultsets gets implemented (it was posted as a POC during v11
>> development), this will be needed too.
>
> See previous patch here:
> https://www.postgresql.org/message-id/flat/4580ff7b-d610-eaeb-e06f-4d686896b93b%402ndquadrant.com
>
> In that patch, I discussed the specific ways in which \timing works in
> psql and how that conflicts with multiple result sets. What is the
> solution to that in this patch?
\timing was kind of a ugly feature to work around. The good intention
behind \timing is that it should reflect the time to perform the query
from the client perspective, but should not include processing the
results.
However, if a message results in several queries, they are processed as
they arrive, so that \timing reports the time to perform all queries and
the time to process all but the last result.
Although on paper we could try to get all results first, take the time,
then process them, this does not work in the general case because COPY
takes on the connection so you have to process its result before switching
to the next result.
There is also some stuff to handle notices which are basically send as
events when they occur, so that the notice shown are related to the
result under processing.
--
Fabien.