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.
