Thread: 9.5Beta1 psql wrapped format expanded output

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.

I've made the screen absurdly small before running and capturing this,
so the email program wouldn't try to re-wrap the lines.

echo -e '\pset format wrapped' \\n "select repeat('1234567890',20)"|
pgsql/REL9_5_BETA1/bin/psql -Xx




Output format is wrapped.
-[ RECORD 1 ]----------------------------------
repeat | 12345678901234567890123456789012345678
.      |.90123456789012345678901234567890123456
.      |.78901234567890123456789012345678901234
.      |.56789012345678901234567890123456789012
.      |.34567890123456789012345678901234567890
.      |.1234567890

Cheers,

Jeff

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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.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.
        regards, tom lane

On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.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.

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <span
dir="ltr"><<ahref="mailto:jeff.janes@gmail.com" target="_blank">jeff.janes@gmail.com</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">OnFri, Oct 23, 2015 at 3:06 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>
wrote:<br/> > Alvaro Herrera <<a href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>
writes:<br/> >> Jeff Janes wrote:<br /> >>> When I use psql with wrapped format with expanded output, I
getthe<br /> >>> period that is supposed to be at the end of the line being at the<br /> >>>
beginningof the next line.<br /> >>><br /> >>> Can anyone else verify this?  I want to verify it is
notsome local<br /> >>> issue before looking into it too far.<br /> ><br /> >> Yes, I see it too.<br
/>><br /> > Me too.  It looks like the code is overoptimistic about how much data<br /> > it can print on one
line.<br/> ><br /> > 9.4 does not seem to try to wrap at all in this case.<br /><br /></span>Yeah, support for
wrappingin the extended format was added in 9.4 but<br /> reverted from that branch.<br /><br /> This patch seems to
fixthe problem although I don't fully understand why.<br /><br /> The reason swidth is 3 greater with border 1 than it
iswith border 0<br /> is that border 1 reserves a space at the right edge for the<br /> continuation period, while
border0 doesn't reserve a space and simply<br /> takes it out of the printable area if needed.<br /><br /> Why swidth
forborder 2 is three greater than it is with border 1, I<br /> don't really know.<br /></blockquote></div><br
/></div><divclass="gmail_extra">Now I see why.  Border 2 doesn't just add a '|' on either end of the line, but also
addsa space to the left end, so that the "column" name is not hard up against the preceding '|'<br /><br /></div><div
class="gmail_extra">SoI think my patch is correct.<br /><br /></div><div class="gmail_extra">Cheers,<br /><br
/></div><divclass="gmail_extra">Jeff<br /></div></div> 

Jeff Janes <jeff.janes@gmail.com> writes:
> On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff.janes@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

On Mon, Nov 30, 2015 at 2:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff.janes@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