Newlines not printed out as newlines

[henderea]

Description

If I try to perform a query that includes a newline in the output, pgcli shows \n instead of having a line break. I have tried the same thing with psql and it works as expected.

Try the following query:

select E'a\nb';

In psql, it will show this:

 ?column?
----------
 a       +
 b
(1 row)

In pgcli, it is showing a\nb as the column value. As in a literal \n. Ideally, it would either match psql or just have a newline without the + character (or with a different character).

Your environment

• [x] Please provide your OS and version information. - macOS 10.15.7
• [x] Please provide your CLI version. 3.2.0
• [x] What is the output of pip freeze command.

3to2==1.1.1
agate==1.6.3
agate-dbf==0.2.2
agate-excel==0.2.5
agate-sql==0.5.8
appdirs==1.4.4
applib==1.2
arrow==1.2.1
b2==3.2.0
b2sdk==1.14.0
Babel==2.9.1
certifi==2021.10.8
chardet==4.0.0
charset-normalizer==2.0.9
class-registry==2.1.2
cli-helpers==2.2.0
click==8.0.3
cmdln==2.0.0
CodeIntel==2.0.0
configobj==5.0.6
csvkit==1.0.6
dbfread==2.0.7
docutils==0.16
esprima==4.0.1
et-xmlfile==1.1.0
funcsigs==1.0.2
future==0.18.2
greenlet==1.1.2
humanize==3.13.1
idna==3.3
importlib-metadata==4.8.3
Inflector==3.0.1
isodate==0.6.1
jdcal==1.4.1
leather==0.3.4
libclang-py3==3.9.0
logfury==1.0.1
olefile==0.46
openpyxl==3.0.9
parsedatetime==2.6
pendulum==2.1.2
pgcli==3.2.0
pgspecial==1.13.0
phx-class-registry==3.0.5
prompt-toolkit==3.0.24
psycopg2==2.9.3
Pygments==2.11.1
PyICU==2.8
pyobjc-core==8.1
pyobjc-framework-Cocoa==8.1
pyobjc-framework-Quartz==8.1
python-dateutil==2.8.2
python-slugify==5.0.2
pytimeparse==1.1.8
pytz==2021.3
pytzdata==2020.1
requests==2.26.0
rst2ansi==0.1.5
setproctitle==1.2.2
simplejson==3.17.6
six==1.16.0
SQLAlchemy==1.4.29
sqlparse==0.4.2
tabulate==0.8.9
terminaltables==3.1.10
text-unidecode==1.3
tqdm==4.62.3
typing_extensions==4.0.1
Unidecode==1.3.2
urllib3==1.26.7
wcwidth==0.2.5
xlrd==2.0.1
zipp==3.6.0
zope.cachedescriptors==4.3.1

[j-bennet]

Possibly same issue as https://github.com/dbcli/mycli/issues/1024.

[henderea]

Ah, sorry about that. I searched a bunch, but searching "\n" had way too many results so I struggled to sort through them, and I didn't find that one with a search for the term newline.

[j-bennet]

The same issue is in mycli repo, you were searching in pgcli, it's all good!

[j-bennet]

@henderea What table_format is specified in your pgcli config? It may not be the same issue. Pgcli uses psql format by default, not ascii like mycli does.

[henderea]

I'm away from my computer at the moment, but if double (as in double-thickness bordered table) is the sort of thing you're looking for, then that's the setting.

The issue also happens if I switch the pager to pspg (normally I have it set to less)

[henderea]

Yeah, this is what I have set:

table_format = double

Also, for my pager, both of these have the issue (but work fine otherwise):

pager = less -SRXF

pager = /usr/local/bin/pspg --csv --rr=2 --quit-if-one-screen --ignore-case --csv-header on -s 17

As a note, I can confirm that the issue is not pspg because this works as expected:

psql -c "select E'a\nb';" -P format=csv postgres | pspg --csv --rr=2 --quit-if-one-screen --ignore-case --csv-header on -s 17

And shows:

┌──────────┐
│ ?column? │
├──────────┤
│ a       ↵│
│ b        │
└──────────┘
(2 rows)

So the issue seems to be specifically in pgcli. I originally discovered the issue with a query that had wider results than what could fit on my screen, so it was definitely using the pager there. I don't seem to be able to force the pager for my example query in pgcli because the results are so small, but the pager clearly isn't the issue anyway.

[henderea]

Oh, hey. I just tried table_format = psql, and it worked fine with that:

+----------+
| ?column? |
|----------|
| a        |
| b        |
+----------+
SELECT 1
Time: 0.036s

So the issue seems to be the "double" format, and maybe certain others. Probably not limited to pgcli, then.

Also, when I use table_format = csv with the pspg pager I pasted in my previous comment, it also works fine, showing a result matching what I got with the psql command. So it's definitely limited to specific table formats.