On Mon, Nov 30, 2015 at 2:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff.ja...@gmail.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
The wrapping behavior looks good now, and the code is much more understandable. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
