Re: psql - pager support - using invisible chars for signalling end of report

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql - pager support - using invisible chars for signalling end of report
Date: 2020-04-25 03:52:32
Message-ID: CAFj8pRC-qNNNcdge2+=vk54eA26nipOH40nkfxjxazjBgwGmPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

so 25. 4. 2020 v 2:12 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > pá 24. 4. 2020 v 21:33 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2020-04-25 09:05:35 Re: Anybody want to check for Windows timezone updates?
Previous Message Peter Geoghegan 2020-04-25 01:37:44 Using Valgrind to detect faulty buffer accesses (no pin or buffer content lock held)