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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
Attachments:
psql_wrap_extend_fix.patchapplication/octet-stream; name=psql_wrap_extend_fix.patchDownload
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
new file mode 100644
index ad4350e..1894743
*** a/src/bin/psql/print.c
--- b/src/bin/psql/print.c
*************** print_aligned_vertical(const printTableC
*** 1367,1375 ****
{
/*
* For border = 1, one for the pipe (|) in the middle between the
! * two spaces.
*/
! swidth = 3;
}
else
--- 1367,1376 ----
{
/*
* For border = 1, one for the pipe (|) in the middle between the
! * two spaces, one for the space on the right side reserverd for the
! * continuation marker.
*/
! swidth = 4;
}
else
On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
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.
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 '|'
So I think my patch is correct.
Cheers,
Jeff
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 hadif ((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