Re: psql - pager support - using invisible chars for signalling end of report
От | Thomas Munro |
---|---|
Тема | Re: psql - pager support - using invisible chars for signalling end of report |
Дата | |
Msg-id | CA+hUKGJHUabh-QOBj3kLv4oia8fJXayEWbGhw7oSyuXHjKoTNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: psql - pager support - using invisible chars for signalling endof report (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: psql - pager support - using invisible chars for signalling end of report
Re: psql - pager support - using invisible chars for signalling end of report |
Список | pgsql-hackers |
On Sat, Apr 25, 2020 at 3:53 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > so 25. 4. 2020 v 2:12 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: >> Pavel Stehule <pavel.stehule@gmail.com> writes: >> > pá 24. 4. 2020 v 21:33 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: >> >> And what will happen when those characters are in the data? >> >> > It will be used on pager side as signal so previous rows was really last >> > row of result, and new row will be related to new result. >> >> In other words, it will misbehave badly if those characters appear >> in the query result. Doesn't sound acceptable to me. > > > It should not be problem, I think > > a) it can be applied as special char only when row before was empty > b) psql formates this char inside query result, so should not be possible to find binary this value inside result. > > postgres=# select e'AHOJ' || chr(5) || 'JJJJ'; > ┌──────────────┐ .> │ ?column? │ > ╞══════════════╡ > │ AHOJ\x05JJJJ │ > └──────────────┘ > (1 row) This sounds better than the QUERY_SEPARATOR hack from commit 664d757531e, and similar kludges elsewhere. I think Pavel and David are right about NUL being impossible in psql query output, no?
В списке pgsql-hackers по дате отправления: