Re: [HACKERS] psql's \r broken since e984ef5861d
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] psql's \r broken since e984ef5861d |
Дата | |
Msg-id | 11958.1500516953@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql's \r broken since e984ef5861d (Julien Rouhaud <julien.rouhaud@dalibo.com>) |
Ответы |
Re: [HACKERS] psql's \r broken since e984ef5861d
|
Список | pgsql-hackers |
Julien Rouhaud <julien.rouhaud@dalibo.com> writes: > On 20/07/2017 03:34, Tom Lane wrote: >> Works for me. Please describe exactly what misbehavior you're seeing. > Here's a simple test case, last \p still show the query buffer: Ah. I don't feel like trawling the archives for the discussion right now, but I believe this was an intentional change to make the behavior more consistent. Prior versions did things weirdly differently depending on whether you'd typed anything, eg modifying your example slightly: regression=# select version(); version ----------------------------------------------------------------------------------------------------------PostgreSQL 9.6.3on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit (1 row) regression=# \p select version(); regression=# mistake regression-# \r Query buffer reset (cleared). regression=# \p select version(); regression=# \g version ----------------------------------------------------------------------------------------------------------PostgreSQL 9.6.3on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit (1 row) I think we felt that throwing away the previous-query buffer when we didn't have to was generally to be avoided, so we wanted to standardize on this behavior not the other one. Do you think differently? I have some recollection that there were also cases where \p would print something different than what \g would execute, which of course is quite nasty. regards, tom lane
В списке pgsql-hackers по дате отправления: