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

From Peter Eisentraut
Subject Re: psql - add SHOW_ALL_RESULTS option
Date
Msg-id f54c68a7-a8ac-d538-ec7c-ee7e090fefd8@enterprisedb.com
Whole thread Raw
In response to Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: psql - add SHOW_ALL_RESULTS option  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On 12.03.22 17:27, Fabien COELHO wrote:
> 
>>> Are you planning to send a rebased patch for this commit fest?
>>
>> Argh, I did it in a reply in another thread:-( Attached v15.
>>
>> So as to help moves things forward, I'd suggest that we should not to 
>> care too much about corner case repetition of some error messages 
>> which are due to libpq internals, so I could remove the ugly buffer 
>> reset from the patch and have the repetition, and if/when the issue is 
>> fixed later in libpq then the repetition will be removed, fine! The 
>> issue is that we just expose the strange behavior of libpq, which is 
>> libpq to solve, not psql.
> 
> See attached v16 which removes the libpq workaround.

I suppose this depends on

https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com

getting committed, because right now this makes the psql TAP tests fail 
because of the duplicate error message.

How should we handle that?


In this part of the patch, there seems to be part of a sentence missing:

+ * Marshal the COPY data.  Either subroutine will get the
+ * connection out of its COPY state, then
+ * once and report any error. Return whether all was ok.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Next
From: Pavel Borisov
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15