Re: 9.5Beta1 psql wrapped format expanded output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
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-11-30 22:59:47
Message-ID: 26599.1448924387@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> Why swidth for border 2 is three greater than it is with border 1, I
>> don't really know.

> Now I see why. Border 2 doesn't just add a '|' on either end of the line,
> but also adds a space to the left end, so that the "column" name is not
> hard up against the preceding '|'

I looked this over and concluded that the real problem was that the logic
that added space for newline/wrap marker columns was many bricks shy of a
load. For example it had

if ((opt_border < 2) &&
((hmultiline &&
(format == &pg_asciiformat_old)) ||
(dmultiline &&
(format != &pg_asciiformat_old))))
iwidth++; /* for newline indicators */

which aside from being nearly unreadable conflated the header wrap column
with the data wrap column; and even if those had identical conditions for
being added, which they don't, you'd need to count two more columns here
not just one.

I rewrote it to correspond more accurately to what the printing logic
actually does, and pushed it as 0e0776bc9. Let me know if you still see
any problems here.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-11-30 23:04:27 Re: On-demand running query plans using auto_explain and signals
Previous Message Alvaro Herrera 2015-11-30 22:21:16 Re: Remaining 9.5 open items