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
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.
Show quoted text
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
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.
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
Show quoted text
regards, tom lane
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?
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
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