From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 9.5Beta1 psql wrapped format expanded output |
Date: | 2015-10-24 00:11:32 |
Message-ID: | CAMkU=1yyPy5DNmfd-r4meNaJsyuHzkvy1BD-aT=1qR_6_68UZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Jeff Janes wrote:
>>> When I use psql with wrapped format with expanded output, I get the
>>> period that is supposed to be at the end of the line being at the
>>> beginning of the next line.
>>>
>>> Can anyone else verify this? I want to verify it is not some local
>>> issue before looking into it too far.
>
>> Yes, I see it too.
>
> Me too. It looks like the code is overoptimistic about how much data
> it can print on one line.
>
> 9.4 does not seem to try to wrap at all in this case.
Yeah, support for wrapping in the extended format was added in 9.4 but
reverted from that branch.
This patch seems to fix the problem although I don't fully understand why.
The reason swidth is 3 greater with border 1 than it is with border 0
is that border 1 reserves a space at the right edge for the
continuation period, while border 0 doesn't reserve a space and simply
takes it out of the printable area if needed.
Why swidth for border 2 is three greater than it is with border 1, I
don't really know.
Attachment | Content-Type | Size |
---|---|---|
psql_wrap_extend_fix.patch | application/octet-stream | 631 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-24 00:29:03 | Re: make Gather node projection-capable |
Previous Message | Dave Cramer | 2015-10-23 23:49:16 | Re: [HACKERS] JDBC driver debug out? |