Re: psql - add SHOW_ALL_RESULTS option - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: psql - add SHOW_ALL_RESULTS option
Date
Msg-id alpine.DEB.2.22.394.2201291530010.399637@pseudo
Whole thread Raw
In response to Re: psql - add SHOW_ALL_RESULTS option  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: psql - add SHOW_ALL_RESULTS option
List pgsql-hackers
Hello Peter,

>>> It would be better to do without.  Also, it makes one wonder how others 
>>> are supposed to use this multiple-results API properly, if even psql can't 
>>> do it without extending libpq. Needs more thought.
>> 
>> Fine with me! Obviously I'm okay if libpq is repaired instead of writing 
>> strange code on the client to deal with strange behavior.
>
> I have a new thought on this, as long as we are looking into libpq.  Why 
> can't libpq provide a variant of PQexec() that returns all results, instead 
> of just the last one.  It has all the information, all it has to do is return 
> the results instead of throwing them away.  Then the changes in psql would be 
> very limited, and we don't have to re-invent PQexec() from its pieces in 
> psql.  And this would also make it easier for other clients and user code to 
> make use of this functionality more easily.
>
> Attached is a rough draft of what this could look like.  It basically works. 
> Thoughts?

My 0.02€:

With this approach results are not available till the last one has been 
returned? If so, it loses the nice asynchronous property of getting 
results as they come when they come? This might or might not be desirable 
depending on the use case. For "psql", ISTM that we should want 
immediate and asynchronous anyway??

I'm unclear about what happens wrt to client-side data buffering if 
several large results are returned? COPY??

Also, I guess the user must free the returned array on top of closing all 
results?

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?
Next
From: Bharath Rupireddy
Date:
Subject: Re: Allow users to choose what happens when recovery target is not reached