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.2201231810310.1496591@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
Hallo Peter,

>> Attached v14 moves the status extraction before the possible clear. I've 
>> added a couple of results = NULL after such calls in the code.
>
> In the psql.sql test file, the test I previously added concluded with \set 
> ECHO none, which was a mistake that I have now fixed.  As a result, the tests 
> that you added after that point didn't show their input lines, which was 
> weird and not intentional.  So the tests will now show a different output.

Ok.

> I notice that this patch has recently gained a new libpq function.  I gather 
> that this is to work around the misbehaviors in libpq that we have discussed.

Indeed.

> 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.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: PSA: Autoconf has risen from the dead
Next
From: Andrew Dunstan
Date:
Subject: Re: fairywren is generating bogus BASE_BACKUP commands