Re: psql - add SHOW_ALL_RESULTS option
От | Kyotaro Horiguchi |
---|---|
Тема | Re: psql - add SHOW_ALL_RESULTS option |
Дата | |
Msg-id | 20190726.131704.86173346.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: psql - add SHOW_ALL_RESULTS option (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: psql - add SHOW_ALL_RESULTS option
|
Список | pgsql-hackers |
Hello. At Thu, 25 Jul 2019 21:42:11 +0000 (GMT), Fabien COELHO <coelho@cri.ensmp.fr> wrote in <alpine.DEB.2.21.1907252135060.21130@lancre> > > Bonsoir Daniel, > > > FYI you forgot to remove that bit: > > > > + "SINGLELINE|SINGLESTEP|SHOW_ALL_RESULTS")) > > Indeed. I found another such instance in "help.c". > > > Also copydml does not seem to be exercised with combined > > queries, so do we need this chunk: > > > --- a/src/test/regress/sql/copydml.sql > > Yep, because I reorganized the notice code significantly, and I wanted > to be sure that the right notices are displayed in the right order, > which does not show if the trigger just says "NOTICE: UPDATE 8". > > Attached a v2 for the always-show-all-results variant. Thanks for the > debug! I have some comments on this patch. I'm +1 for always output all results without having knobs. Documentation (psql-ref.sgml) has another place that needs the same amendment. Looking the output for -t, -0, -A or something like, we might need to introduce result-set separator. # -eH looks broken for me but it would be another issue. Valid setting of FETCH_COUNT disables this feature. I think it is unwanted behavior. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: