Re: psql - pager support - using invisible chars for signalling end of report - Mailing list 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?