Re: wrapping in extended mode doesn't work well with default pager

From: Greg Stark <stark(at)mit(dot)edu>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Sergey Muraviov <sergey(dot)k(dot)muraviov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Emre Hasegeli <emre(at)hasegeli(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wrapping in extended mode doesn't work well with default pager
Date: 2014-05-17 16:10:08
Message-ID: CAM-w4HPXQxM=F3YyLkdUGh71-JxtOdjbtRt6gcaZGOZd4FRPVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm trying to review all the combinations of the options exhaustively
but in the process I noticed a few pre-existing psql oddities. Both of
these are present in 9.3:

Can anyone explain this? It's linestyle=old-style, border=1,
expanded=off, format=aligned. It looks like it's using new-style ascii
indicators in the header but old-style in the data cells:

a | a
+ |+ b
+ b |+
----------------------+--------------------
xx | yyyyyyyyyyyyyyyyyy
xxxx | yyyyyyyyyyyyyyyy
xxxxxx : yyyyyyyyyyyyyy
xxxxxxxx : yyyyyyyyyyyy
xxxxxxxxxx : yyyyyyyyyy
xxxxxxxxxxxx : yyyyyyyy
xxxxxxxxxxxxxx : yyyyyy
xxxxxxxxxxxxxxxx : yyyy
xxxxxxxxxxxxxxxxxx : yy
xxxxxxxxxxxxxxxxxxxx :
(2 rows)

Also the line-ending white-space is very odd here. It's
linestyle=old-ascii, border=0, expanded=off, format=aligned. There's
an extra space on the header and the first line of the data, but not
on the subsequent lines of the data:

a a
+ b
b +
-------------------- ------------------
xx yyyyyyyyyyyyyyyyyy
xxxx yyyyyyyyyyyyyyyy
xxxxxx yyyyyyyyyyyyyy
xxxxxxxx yyyyyyyyyyyy
xxxxxxxxxx yyyyyyyyyy
xxxxxxxxxxxx yyyyyyyy
xxxxxxxxxxxxxx yyyyyy
xxxxxxxxxxxxxxxx yyyy
xxxxxxxxxxxxxxxxxx yy
xxxxxxxxxxxxxxxxxxxx
(2 rows)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-05-17 16:23:51 Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Previous Message Tom Lane 2014-05-17 14:55:22 Re: Allowing join removals for more join types