Re: psql - add SHOW_ALL_RESULTS option

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql - add SHOW_ALL_RESULTS option
Date: 2022-03-17 14:51:45
Message-ID: f54c68a7-a8ac-d538-ec7c-ee7e090fefd8@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2022-03-17 14:54:31 Re: Add 64-bit XIDs into PostgreSQL 15
Previous Message Tom Lane 2022-03-17 14:47:03 Re: Granting SET and ALTER SYSTE privileges for GUCs