On 23.01.22 18:17, Fabien COELHO wrote:
>> But I think if we are adding a libpq API function to work around a
>> misbehavior in libpq, we might as well fix the misbehavior in libpq to
>> begin with. Adding a new public libpq function is a significant step,
>> needs documentation, etc.
>
> I'm not so sure.
>
> The choice is (1) change the behavior of an existing function or (2) add
> a new function. Whatever the existing function does, the usual anwer to
> API changes is "someone is going to complain because it breaks their
> code", so "Returned with feedback", hence I did not even try. The
> advantage of (2) is that it does not harm anyone to have a new function
> that they just do not need to use.
>
>> 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?