Re: psql - add SHOW_ALL_RESULTS option
От | Fabien COELHO |
---|---|
Тема | Re: psql - add SHOW_ALL_RESULTS option |
Дата | |
Msg-id | alpine.DEB.2.22.394.2006061622300.32228@pseudo обсуждение исходный текст |
Ответ на | Re: psql - add SHOW_ALL_RESULTS option (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: psql - add SHOW_ALL_RESULTS option
|
Список | pgsql-hackers |
Hello, >> This patch was marked as ready for committer, but clearly there's an >> ongoin discussion about what should be the default behavoir, if this >> breaks existing apps etc. So I've marked it as "needs review" and moved >> it to the next CF. > > The issue is that root (aka Tom) seems to be against the feature, and would > like the keep it as current. Although my opinion is that the previous > behavior is close to insane, I'm ready to resurect the guc to control the > behavior so that it would be possible, or even the default. > > Right now I'm waiting for a "I will not veto it on principle" from Tom (I'm > okay with a reject based on bad implementation) before spending more time on > it: Although my time is given for free, it is not a good reason to send it > down the drain if there is a reject coming whatever I do. > > Tom, would you consider the feature acceptable with a guc to control it? Tom, I would appreciate if you could answer this question. For me, the current behavior is both stupid and irritating: why would pg decide to drop the result of a query that I carefully typed?. It makes the multi-query feature basically useless from psql, so I did not resurrect the guc, but I will if it would remove a veto. In the meantime, here is a v9 which also fixes the behavior when using \watch, so that now one can issue several \;-separated queries and have their progress shown. I just needed that a few days ago and was disappointed but unsurprised that it did not work. Watch does not seem to be tested anywhere, I kept it that way. Sigh. -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: