Re: 9.5Beta1 psql wrapped format expanded output

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

In response to

Responses

Browse pgsql-hackers by date

  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?