Re: psql - add SHOW_ALL_RESULTS option

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: psql - add SHOW_ALL_RESULTS option
Дата
Msg-id f54c68a7-a8ac-d538-ec7c-ee7e090fefd8@enterprisedb.com
обсуждение исходный текст
Ответ на Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Granting SET and ALTER SYSTE privileges for GUCs
Следующее
От: Pavel Borisov
Дата:
Сообщение: Re: Add 64-bit XIDs into PostgreSQL 15