Re: psql - add SHOW_ALL_RESULTS option

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.