Thread: psql - pager support - using invisible chars for signalling end of report
Hi
Last release of pspg supports stream mode - it means so you can open psql in one terminal, redirect output to named pipe. In second terminal you can start pspg and read input from named pipe. Then you can see and edit SQL in one terminal, and you can see a result in second terminal.
It is working very well, but it is not too robust how I would. I miss a some message in communication that can ensure synchronization - some special char that can be used as separator between two results. Now, it is based on detection and evaluation positions of empty rows.
I had a idea using some invisible chars, that are usually ignored (and use these special characters only when user would it).
There are possible characters:
03 ETX .. end of text
28 FS .. file separator
29 GS .. group separator
What do you think about this?
Regards
Pavel
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I had a idea using some invisible chars, that are usually ignored (and use
> these special characters only when user would it).
And what will happen when those characters are in the data?
regards, tom lane
Re: psql - pager support - using invisible chars for signalling endof report
From
Pavel Stehule
Date:
pá 24. 4. 2020 v 21:33 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I had a idea using some invisible chars, that are usually ignored (and use
> these special characters only when user would it).
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.
regards, tom lane
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.
regards, tom lane
Re: psql - pager support - using invisible chars for signalling endof report
From
"David G. Johnston"
Date:
On Fri, Apr 24, 2020 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
Random thought but NUL isn't allowed in data so could it be used as a protocol flag?
David J.
Re: psql - pager support - using invisible chars for signalling endof report
From
Pavel Stehule
Date:
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)
┌──────────────┐
│ ?column? │
╞══════════════╡
│ AHOJ\x05JJJJ │
└──────────────┘
(1 row)
Regards
Pavel
regards, tom lane
Re: psql - pager support - using invisible chars for signalling end of report
From
Thomas Munro
Date:
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?
Re: psql - pager support - using invisible chars for signalling end of report
From
Daniel Gustafsson
Date:
> On 6 Sep 2023, at 05:07, Thomas Munro <thomas.munro@gmail.com> wrote: > 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? +1, I would love to be able to rip out that hack. -- Daniel Gustafsson
Re: psql - pager support - using invisible chars for signalling end of report
From
Peter Eisentraut
Date:
On 06.09.23 05:07, Thomas Munro wrote:
> 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?
Note:
-z, --field-separator-zero
set field separator for unaligned output to
zero byte
-0, --record-separator-zero
set record separator for unaligned output to
zero byte