Re: psql - pager support - using invisible chars for signalling endof report - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: psql - pager support - using invisible chars for signalling endof report
Date
Msg-id CAFj8pRC-qNNNcdge2+=vk54eA26nipOH40nkfxjxazjBgwGmPw@mail.gmail.com
Whole thread Raw
In response to Re: psql - pager support - using invisible chars for signalling end of report  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: psql - pager support - using invisible chars for signalling end of report
List pgsql-hackers


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)

Regards

Pavel


                        regards, tom lane

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Using Valgrind to detect faulty buffer accesses (no pin or buffercontent lock held)
Next
From: Juan José Santamaría Flecha
Date:
Subject: Re: Anybody want to check for Windows timezone updates?