Re: [HACKERS] Problem with displaying wide tables in psql
On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut pete...@gmx.net wrote: Please fix this compiler warning. I think it came from this patch. Oops, I fixed it in a previous version but didn't notice it had crept back in in the back-and-forth. Will do. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Please fix this compiler warning. I think it came from this patch. print.c: In function ‘print_aligned_vertical’: print.c:1354:10: error: pointer targets in passing argument 1 of ‘strlen_max_width’ differ in signedness [-Werror=pointer-sign] encoding); ^ print.c:126:12: note: expected ‘unsigned char *’ but argument is of type ‘char *’ static int strlen_max_width(unsigned char *str, int *target_width, int encoding); ^ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: 2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@gmx.net: Please fix this compiler warning. I think it came from this patch. print.c: In function 'print_aligned_vertical': print.c:1354:10: error: pointer targets in passing argument 1 of 'strlen_max_width' differ in signedness [-Werror=pointer-sign] encoding); ^ print.c:126:12: note: expected 'unsigned char *' but argument is of type 'char *' static int strlen_max_width(unsigned char *str, int *target_width, int encoding); ^ fixed Your patch has been committed by Greg not so long ago, you should send for this warning a patch rebased on the latest master branch commit :) -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
rebased
2014-04-29 7:43 GMT+04:00 Michael Paquier michael.paqu...@gmail.com:
On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@gmx.net:
Please fix this compiler warning. I think it came from this patch.
print.c: In function 'print_aligned_vertical':
print.c:1354:10: error: pointer targets in passing argument 1 of
'strlen_max_width' differ in signedness [-Werror=pointer-sign]
encoding);
^
print.c:126:12: note: expected 'unsigned char *' but argument is of type
'char *'
static int strlen_max_width(unsigned char *str, int *target_width, int
encoding);
^
fixed
Your patch has been committed by Greg not so long ago, you should send
for this warning a patch rebased on the latest master branch commit :)
--
Michael
--
Best regards,
Sergey Muraviov
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 0eb..b2f56a3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1350,8 +1350,7 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
{
int swidth, twidth = hwidth + 1;
fputs(hline? format-header_nl_left: , fout);
-strlen_max_width((char *) hlineptr[hline].ptr, twidth,
- encoding);
+strlen_max_width(hlineptr[hline].ptr, twidth, encoding);
fprintf(fout, %-s, hlineptr[hline].ptr);
swidth = hwidth - twidth;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Greg Stark st...@mit.edu writes: I expect this regression test to fail on platforms that don't support utf-8 client-side (I'm assuming we such things?). I don't have such a platform here and I'm not sure how it would fail so I want to go ahead and apply it and grab the output to add the alternate output when it fails on the build-farm. Would that be ok? Are you expecting to carry an alternate expected file for every possible encoding choice? That does not seem workable to me, and even if we could do it the cost/benefit ratio would be pretty grim. I think you should drop the UTF8-dependent tests. In other words: there are no encoding dependencies in the existing standard regression tests. This feature is not the place to start adding them, and two weeks past feature freeze is not the time to start adding them either. We don't have time right now to shake out a whole new set of platform dependencies in the regression tests. If you feel these tests must be preserved someplace, you could add a new regression test that isn't run by default, following in the footsteps of collate.linux.utf8. 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
Re: [HACKERS] Problem with displaying wide tables in psql
Not sure what other encodings you mean. Psql uses utf8 for the border and the test uses utf8 to test the formatting. I was only anticipating an error on platforms where that didn't work. I would lean towards having it but I'm fine following your judgement, especially given the timing. -- greg
Re: [HACKERS] Problem with displaying wide tables in psql
Greg Stark st...@mit.edu writes: Not sure what other encodings you mean. Psql uses utf8 for the border and the test uses utf8 to test the formatting. I was only anticipating an error on platforms where that didn't work. Well, there are two likely misbehaviors if the regression test is being run in some other encoding: 1. If it's a single-byte encoding, you probably won't get any bad-encoding complaints, but the code will think the utf8 characters represent multiple logical characters, resulting in (at least) spacing differences. It's possible that all single-byte encodings would act the same, but I'm not sure. 2. If it's a multi-byte encoding different from utf8, you're almost certainly going to get badly-encoded-data complaints, at different places depending on the particular encoding. I don't remember how many different multibyte encodings we support, but I'm pretty sure we'd need a separate expected file for each one. Plus at least one for the single-byters. The real problem is that I don't have a lot of confidence that the buildfarm would provide us with full coverage of all the encodings that somebody might use in the field. So we might not find out about omissions or wrong expected-files until after we ship. Anyway, the bottom line for me is that this test isn't worth that much trouble. I'm okay with putting it in as a separate test file that we don't support running in non-utf8 encodings. 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
Re: [HACKERS] Problem with displaying wide tables in psql
Hi.
I've done some corrections for printing newline and wrap indicators.
Please review the attached patch.
2014-04-11 0:14 GMT+04:00 Sergey Muraviov sergey.k.murav...@gmail.com:
Hi.
Thanks for your tests.
I've fixed problem with headers, but got new one with data.
I'll try to solve it tomorrow.
2014-04-10 18:45 GMT+04:00 Greg Stark st...@mit.edu:
Ok, So I've hacked on this a bit. Below is a test case showing the
problems I've found.
1) It isn't using the newline and wrap indicators or dividing lines.
2) The header is not being displayed properly when it contains a newline.
I can hack in the newline and wrap indicators but the header
formatting requires reworking the logic a bit. The header and data
need to be stepped through in parallel rather than having a loop to
handle the wrapping within the handling of a single line. I don't
really have time for that today but if you can get to it that would be
fine,
--
Best regards,
Sergey Muraviov
--
Best regards,
Sergey Muraviov
From 5e0f44994d04a81523920a78d3a35603e919170c Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Fri, 11 Apr 2014 11:03:41 +0400
Subject: [PATCH] Using newline and wrap indicators
---
src/bin/psql/print.c | 130 +++
1 file changed, 110 insertions(+), 20 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..6463162 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,13 +1234,56 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+ if (cont-opt-format == PRINT_WRAPPED)
+ {
+ int output_columns = 0;
+
+ /*
+ * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+ */
+ if (cont-opt-columns 0)
+ output_columns = cont-opt-columns;
+ else
+ {
+ if (cont-opt-env_columns 0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+ else
+ {
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+ output_columns = screen_size.ws_col;
+ }
+#endif
+ }
+
+ output_columns -= hwidth;
+
+ if (opt_border == 0)
+ output_columns -= 1;
+ else
+ {
+ output_columns -= 3; /* -+- */
+
+ if (opt_border 1)
+output_columns -= 4; /* +--+ */
+ }
+
+ if (output_columns 0 dwidth output_columns)
+ dwidth = output_columns;
+ }
+
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
printTextRule pos;
- int line_count,
+ int dline,
+ hline,
dcomplete,
- hcomplete;
+ hcomplete,
+ offset,
+ chars_to_output;
if (cancel_pressed)
break;
@@ -1270,48 +1313,95 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
pg_wcsformat((const unsigned char *) *ptr, strlen(*ptr), encoding,
dlineptr, dheight);
- line_count = 0;
+ dline = hline = 0;
dcomplete = hcomplete = 0;
+ offset = 0;
+ chars_to_output = dlineptr[dline].width;
while (!dcomplete || !hcomplete)
{
+ /* Left border */
if (opt_border == 2)
fprintf(fout, %s , dformat-leftvrule);
+
+ /* Header */
if (!hcomplete)
{
-fprintf(fout, %-s%*s, hlineptr[line_count].ptr,
- hwidth - hlineptr[line_count].width, );
+int swidth = hwidth - hlineptr[hline].width - 1;
+fprintf(fout, %-s, hlineptr[hline].ptr);
+if (swidth 0) /* spacer */
+ fprintf(fout, %*s, swidth, );
-if (!hlineptr[line_count + 1].ptr)
+if (!hlineptr[hline + 1].ptr)
+{
+ fputs( , fout);
hcomplete = 1;
+}
+else
+{
+ fputs(format-nl_right, fout);
+ hline++;
+}
}
else
-fprintf(fout, %*s, hwidth, );
+fprintf(fout, %*s, hwidth + 1, );
+ /* Separator */
if (opt_border 0)
-fprintf(fout, %s , dformat-midvrule);
- else
-fputc(' ', fout);
+fprintf(fout, %s, dformat-midvrule);
+ /* Data */
if (!dcomplete)
{
-if (opt_border 2)
- fprintf(fout, %s\n, dlineptr[line_count].ptr);
+int target_width,
+ bytes_to_output,
+ swidth;
+
+fputs(!dcomplete !offset? : format-wrap_left, fout);
+
+target_width = dwidth;
+bytes_to_output = strlen_max_width(dlineptr[dline].ptr + offset,
+ target_width, encoding);
+fputnbytes(fout, (char *)(dlineptr[dline].ptr + offset),
+ bytes_to_output);
+
+chars_to_output -= target_width;
+offset += bytes_to_output;
+
+/* spacer */
+swidth = dwidth - target_width;
+if (swidth 0)
+ fprintf(fout, %*s, swidth, );
+
+if (!chars_to_output)
+{
+ if (!dlineptr[dline + 1].ptr)
+ {
+ fputs( , fout);
+ dcomplete = 1;
+ }
+ else
+ {
+ fputs(format-nl_right, fout);
+ dline++;
+ offset = 0;
+ chars_to_output = dlineptr[dline].width;
+ }
+}
else
- fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
- dwidth - dlineptr[line_count].width, ,
Re: [HACKERS] Problem with displaying wide tables in psql
Looks good.
It's still not doing the old-ascii column dividers but to be honest
I'm not sure what the intended behaviour of old-ascii is. I've noticed
old-ascii only displays the line markers for dividing lines, not the
final one. That seems pretty useless and maybe it's why we switched to
the new ascii mode, I don't recall.
This is the way old-ascii displays when two columns are wrapping -- it
seems pretty confused to me. The headers are displaying newline
markers from the ascii style instead of : indicators in the dividing
line. The : and ; markers are only displayed for the first column, not
the second one.
Maybe since the : and ; markers aren't shown for the final column that
means the expanded mode doesn't have to do anything since the column
is only ever the final column.
++-+
| x |x|
|+y |+ y|
|+z |+ z|
++-+
| x | xxx |
| xx ; |
| xxx: xxx |
| ; xxx |
| x : xxx |
| xx ; xx |
| xxx: xxx |
| ; x |
| x : xxx |
| xx : xx |
| xxx: x |
| : |
| x : xxx |
| xx : xx |
| xxx: x |
| : |
| x : xxx |
| xx : xx |
| xx : x |
| x : |
| xx : xxx |
| xx : xx |
| xx : x |
| xxx: |
| xx : |
| : |
| xx : |
| x : |
| xx : |
| xx |
| xx |
| xxx |
++-+
stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);
┌─[ RECORD 1 ]─┐
│ x↵│ x ↵│
│ y↵│ xx ↵│
│ z │ xxx ↵│
│ │ ↵│
│ │ x ↵│
│ │ xx ↵│
│ │ xxx ↵│
│ │ ↵│
│ │ x ↵│
│ │ xx ↵│
│ │ xxx ↵│
│ │ ↵│
│ │ …│
│ │…x ↵│
│ │ …│
│ │…xx ↵│
│ │ …│
│ │…xxx ↵│
│ │ …│
│ │…↵│
│ │ …│
│ │…x ↵│
│ │ …│
│ │…xx ↵│
│ │ …│
│ │…xxx ↵│
│ │ …│
│ │… │
└───┴──┘
stark=# \pset linestyle ascii
Line style (linestyle) is ascii.
stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);
stark***# stark***# stark-***# +-[ RECORD 1 ]-+
| x+| x +|
| y+| xx +|
| z | xxx +|
| | +|
| | x +|
| | xx +|
| | xxx +|
| | +|
| | x +|
| | xx +|
| | xxx +|
| | +|
| | .|
| |.x +|
| | .|
| |.xx +|
| | .|
| |.xxx +|
| | .|
| |.+|
| | .|
| |.x +|
| | .|
| |.xx +|
| | .|
| |.xxx +|
| | .|
| |. |
+---+--+
stark=# \pset linestyle old-ascii
Line style (linestyle) is old-ascii.
stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);
stark# stark# stark-#
+-[ RECORD 1 ]-+
| x | x|
| y | xx |
| z | xxx |
| | |
| | x|
| | xx |
| | xxx |
| | |
| | x|
| | xx |
| | xxx |
| | |
| | |
| | x|
| | |
| | xx |
| | |
| | xxx |
| | |
| | |
| | |
| | x|
| | |
| | xx |
| | |
| | xxx |
| | |
| | |
+---+--+
stark=# \pset expanded off
Expanded display (expanded) is off.
stark=# \pset columns 40
Target width (columns) is 40.
stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
Re: [HACKERS] Problem with displaying wide tables in psql
I hope that I realized old-ascii logic correctly.
2014-04-11 19:10 GMT+04:00 Greg Stark st...@mit.edu:
Looks good.
It's still not doing the old-ascii column dividers but to be honest
I'm not sure what the intended behaviour of old-ascii is. I've noticed
old-ascii only displays the line markers for dividing lines, not the
final one. That seems pretty useless and maybe it's why we switched to
the new ascii mode, I don't recall.
This is the way old-ascii displays when two columns are wrapping -- it
seems pretty confused to me. The headers are displaying newline
markers from the ascii style instead of : indicators in the dividing
line. The : and ; markers are only displayed for the first column, not
the second one.
Maybe since the : and ; markers aren't shown for the final column that
means the expanded mode doesn't have to do anything since the column
is only ever the final column.
++-+
| x |x|
|+y |+ y|
|+z |+ z|
++-+
| x | xxx |
| xx ; |
| xxx: xxx |
| ; xxx |
| x : xxx |
| xx ; xx |
| xxx: xxx |
| ; x |
| x : xxx |
| xx : xx |
| xxx: x |
| : |
| x : xxx |
| xx : xx |
| xxx: x |
| : |
| x : xxx |
| xx : xx |
| xx : x |
| x : |
| xx : xxx |
| xx : xx |
| xx : x |
| xxx: |
| xx : |
| : |
| xx : |
| x : |
| xx : |
| xx |
| xx |
| xxx |
++-+
--
Best regards,
Sergey Muraviov
From 69d845f05864a5d07a90ee20e10a5cb09b78d1d3 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Fri, 11 Apr 2014 20:55:17 +0400
Subject: [PATCH] Support for old-ascii mode
---
src/bin/psql/print.c | 144 +++
1 file changed, 122 insertions(+), 22 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..2c58cb5 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,13 +1234,56 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+ if (cont-opt-format == PRINT_WRAPPED)
+ {
+ int output_columns = 0;
+
+ /*
+ * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+ */
+ if (cont-opt-columns 0)
+ output_columns = cont-opt-columns;
+ else
+ {
+ if (cont-opt-env_columns 0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+ else
+ {
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+ output_columns = screen_size.ws_col;
+ }
+#endif
+ }
+
+ output_columns -= hwidth;
+
+ if (opt_border == 0)
+ output_columns -= 1;
+ else
+ {
+ output_columns -= 3; /* -+- */
+
+ if (opt_border 1)
+output_columns -= 4; /* +--+ */
+ }
+
+ if (output_columns 0 dwidth output_columns)
+ dwidth = output_columns;
+ }
+
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
printTextRule pos;
- int line_count,
+ int dline,
+ hline,
dcomplete,
- hcomplete;
+ hcomplete,
+ offset,
+ chars_to_output;
if (cancel_pressed)
break;
@@ -1270,48 +1313,105 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
pg_wcsformat((const unsigned char *) *ptr, strlen(*ptr), encoding,
dlineptr, dheight);
- line_count = 0;
+ dline = hline = 0;
dcomplete = hcomplete = 0;
+ offset = 0;
+ chars_to_output = dlineptr[dline].width;
while (!dcomplete || !hcomplete)
{
+ /* Left border */
if (opt_border == 2)
-fprintf(fout, %s , dformat-leftvrule);
+fputs(dformat-leftvrule, fout);
+
+ /* Header */
if (!hcomplete)
{
-fprintf(fout, %-s%*s, hlineptr[line_count].ptr,
- hwidth - hlineptr[line_count].width, );
+int swidth = hwidth - hlineptr[hline].width - 1;
+fputs(hline? format-header_nl_left: , fout);
+fprintf(fout, %-s,
Re: [HACKERS] Problem with displaying wide tables in psql
Sergey Muraviov wrote: I hope that I realized old-ascii logic correctly. I don't know what you changed here, but I don't think we need to preserve old-ascii behavior in the new code, in any way. If you're mimicking something obsolete and the end result of the new feature is not great, perhaps that should be rethought. Can you please provide sample output for the previous version compared to this new version? What changed? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
Re: [HACKERS] Problem with displaying wide tables in psql
There were no support for wrapping and old-ascii line style in expanded
mode at all.
But now they are.
2014-04-11 21:58 GMT+04:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Sergey Muraviov wrote:
I hope that I realized old-ascii logic correctly.
I don't know what you changed here, but I don't think we need to
preserve old-ascii behavior in the new code, in any way. If you're
mimicking something obsolete and the end result of the new feature is
not great, perhaps that should be rethought.
Can you please provide sample output for the previous version compared
to this new version? What changed?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Best regards,
Sergey Muraviov
\pset expanded on
\pset border 2
\pset columns 20
\pset format wrapped
\pset linestyle unicode
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
postgres# y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
postgres# y
postgres# z from (select generate_series(1,10)) as t(n);
┌─[ RECORD 1 ]─┐
│ x↵│ x ↵│
│ y │ xx ↵│
│ │ xxx ↵│
│ │ ↵│
│ │ x ↵│
│ │ xx ↵│
│ │ xxx ↵│
│ │ ↵│
│ │ x ↵│
│ │ xx │
│ x↵│ …│
│ y↵│…yy ↵│
│ z │ …│
│ │…↵│
│ │ …│
│ │…yy ↵│
│ │ ↵│
│ │ yy ↵│
│ │ ↵│
│ │ yy ↵│
│ │ ↵│
│ │ yy ↵│
│ │ │
└───┴──┘
postgres=# \pset linestyle ascii
Line style (linestyle) is ascii.
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+-[ RECORD 1 ]-+
| x+| x +|
| y | xx +|
| | xxx +|
| | +|
| | x +|
| | xx +|
| | xxx +|
| | +|
| | x +|
| | xx |
| x+| .|
| y+|.yy +|
| z | .|
| |.+|
| | .|
| |.yy +|
| | +|
| | yy +|
| | +|
| | yy +|
| | +|
| | yy +|
| | |
+---+--+
postgres=# \pset linestyle old-ascii
Line style (linestyle) is old-ascii.
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+-[ RECORD 1 ]-+
| x | x|
|+y : xx |
| : xxx |
| : |
| : x|
| : xx |
| : xxx |
| : |
| : x|
| : xx |
| x | |
|+y ; yy |
|+z : |
| ; |
| : |
| ; yy |
| : |
| : yy |
| : |
| : yy |
| : |
| : yy |
| : |
+---+--+
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Yeah, I think I agree. I'm pretty happy to commit it without old-ascii doing anything special. It looks to me like old-ascii just isn't very useful for a single column output (like expanded mode is implicitly). Maybe that needs to be fixed but then it needs to be fixed for non expanded mode as well. I don't think this new output is very useful dive it just displays the old-ascii info for the header cells. The header cells never wrap and often have a lot of empty lines so it just looks like noise. I do think the earlier change today was important. It looks great now with the wrap and newline indicators in ascii and Unicode mode. Fwiw I've switched my .psqlrc to use Unicode and wrapped=auto be default. It makes psql way more usable. It's even better than my old technique of running it in Emacs and scrolling left and right. I'll take a look at it this evening and will add regression tests (and probably more comments too!) and commit. I want to try adding Unicode regression tests but I'm not sure what the state of the art is for Unicode fallback behaviour on the build farm. I think there are some existing tests we can copy iirc. -- greg
Re: [HACKERS] Problem with displaying wide tables in psql
Ok, So I've hacked on this a bit. Below is a test case showing the
problems I've found.
1) It isn't using the newline and wrap indicators or dividing lines.
2) The header is not being displayed properly when it contains a newline.
I can hack in the newline and wrap indicators but the header
formatting requires reworking the logic a bit. The header and data
need to be stepped through in parallel rather than having a loop to
handle the wrapping within the handling of a single line. I don't
really have time for that today but if you can get to it that would be
fine,
postgres=***# \pset
Border style (border) is 2.
Target width (columns) is 20.
Expanded display (expanded) is on.
Field separator (fieldsep) is |.
Default footer (footer) is on.
Output format (format) is wrapped.
Line style (linestyle) is unicode.
Null display (null) is .
Locale-adjusted numeric output (numericlocale) is off.
Pager (pager) usage is off.
Record separator (recordsep) is newline.
Table attributes (tableattr) unset.
Title (title) unset.
Tuples only (tuples_only) is off.
postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
┌─[ RECORD 1 ]─┐
│ x │ x│
│ y │ xx │
│ │ xxx │
│ │ │
│ │ x│
│ │ xx │
│ │ xxx │
│ │ │
│ │ x│
│ │ xx │
│ x │ │
│ │ yy │
│ y │ │
│ │ │
│ z │ │
│ │ yy │
│ │ │
│ │ yy │
│ │ │
│ │ yy │
│ │ │
│ │ yy │
│ │ │
└───┴──┘
postgres=***# \pset linestyle ascii
Line style (linestyle) is ascii.
postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+-[ RECORD 1 ]-+
| x | x|
| y | xx |
| | xxx |
| | |
| | x|
| | xx |
| | xxx |
| | |
| | x|
| | xx |
| x | |
| | yy |
| y | |
| | |
| z | |
| | yy |
| | |
| | yy |
| | |
| | yy |
| | |
| | yy |
| | |
+---+--+
postgres=***# \pset columns 30
Target width (columns) is 30.
postgres=***# \pset linestyle unicode
Line style (linestyle) is unicode.
postgres=***# \pset columns 30
Target width (columns) is 30.
postgres=***# \pset expanded off
Expanded display (expanded) is off.
postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
┌───┬┐
│ x↵│ x ↵│
│ y │ y ↵│
│ │ z│
├───┼┤
│ x↵│ yy…│
│ xx ↵│… ↵│
│ xxx ↵│ yy…│
│ ↵│…yy↵│
│ x↵│ yy↵│
│ xx ↵│ ↵│
│ xxx ↵│ yy↵│
│ ↵│ ↵│
│ x↵│ yy↵│
│ x…│ ↵│
│…x │ yy↵│
│ ││
└───┴┘
(1 row)
postgres=***# \pset linestyle ascii
Line style (linestyle) is ascii.
postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y, array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+---++
| x+| x +|
| y | y +|
| | z|
+---++
| x+| yy.|
| xx +|. +|
| xxx +| yy.|
| +|.yy+|
| x+| yy+|
| xx +| +|
| xxx +| yy+|
| +| +|
| x+| yy+|
| x.| +|
|.x | yy+|
| ||
+---++
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Hi. Thanks for your tests. I've fixed problem with headers, but got new one with data. I'll try to solve it tomorrow. 2014-04-10 18:45 GMT+04:00 Greg Stark st...@mit.edu: Ok, So I've hacked on this a bit. Below is a test case showing the problems I've found. 1) It isn't using the newline and wrap indicators or dividing lines. 2) The header is not being displayed properly when it contains a newline. I can hack in the newline and wrap indicators but the header formatting requires reworking the logic a bit. The header and data need to be stepped through in parallel rather than having a loop to handle the wrapping within the handling of a single line. I don't really have time for that today but if you can get to it that would be fine, -- Best regards, Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
Hi. How can I pass or set the value of pset variable for an regression test? The code with ioctl was copied from print_aligned_text function, which has a long history. 43ee2282 (Bruce Momjian 2008-05-16 16:59:05 + 680) if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1) 2014-04-08 20:27 GMT+04:00 Greg Stark st...@mit.edu: On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com wrote: I don't think this is easily testable that way - doesn't it rely on determining the width of the terminal? Which you won't have when started from pg_regress? There's a pset variable to set the target width so at least the formatting code can be tested. It would be nice to have the ioctl at least get called on the regression farm so we're sure we aren't doing something unportable. -- greg -- Best regards, Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
How can I pass or set the value of pset variable for an regression test? I just wrote some tests using \pset columns to control the output. Having figured out what the point of the patch is I'm pretty happy with the functionality. It definitely is something I would appreciate having. One thing I noticed is that it's not using the formatting characters to indicate newlines and wrapping. I'm trying to add that myself but it's taking me a bit to figure out what's going on in the formatting code. I do have a feeling this is all rearranging the deck chairs on an obsolete technology and this should all be replaced with a web ui. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
On Sat, Feb 15, 2014 at 11:08 AM, Emre Hasegeli e...@hasegeli.com wrote:
This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.
I'm reviewing this patch.
One thing to comment:
With no doc changes and no regression tests I was halfway inclined to
just reject it out of hand. To be fair there were no regression tests
for wrapped output prior to the patch but still I would have wanted to
see them added. We often pare down regression tests when committing
patches but it's easier to pare them down than write new ones and it
helps show the author's intention.
In this case I'm inclined to expand the regression tests. We've had
bugs in these formatting functions before and at least I find it hard
to touch code like this with any confidence that I'm not breaking
things. Formatting code ends up being pretty spaghetti-like easily and
there are lots of cases so it's easy to unintentionally break cases
you didn't realize you were touching.
In addition there are several cases of logic that looks like this:
if (x)
..
else
{
if (y)
...
else
...
}
I know there are other opinions on this but I find this logic very
difficut to follow. It's almost always clearer to refactor the
branches into a flat if / else if / else if /.../ else form. Even if
it results in some duplication of code (typically there's some trivial
bit of code outside the second if) it's easy to quickly see whether
all the cases are handled and understand whether any of the cases have
forgotten any steps.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
On 2014-04-08 12:15:47 -0400, Greg Stark wrote: With no doc changes and no regression tests I was halfway inclined to just reject it out of hand. To be fair there were no regression tests for wrapped output prior to the patch but still I would have wanted to see them added. We often pare down regression tests when committing patches but it's easier to pare them down than write new ones and it helps show the author's intention. I don't think this is easily testable that way - doesn't it rely on determining the width of the terminal? Which you won't have when started from pg_regress? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
Re: [HACKERS] Problem with displaying wide tables in psql
On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com wrote: I don't think this is easily testable that way - doesn't it rely on determining the width of the terminal? Which you won't have when started from pg_regress? There's a pset variable to set the target width so at least the formatting code can be tested. It would be nice to have the ioctl at least get called on the regression farm so we're sure we aren't doing something unportable. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@gmail.com: New code doesn't work with empty strings but I've done minor optimization for this case. It seems better now. I added some new lines and spaces, removed unnecessary parentheses and marked it as Ready for Committer. fix_psql_print_aligned_vertical_v5.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Thanks. 2014-02-17 12:22 GMT+04:00 Emre Hasegeli e...@hasegeli.com: 2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@gmail.com: New code doesn't work with empty strings but I've done minor optimization for this case. It seems better now. I added some new lines and spaces, removed unnecessary parentheses and marked it as Ready for Committer. -- Best regards, Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
Hi.
Thanks for your review.
2014-02-15 20:08 GMT+04:00 Emre Hasegeli e...@hasegeli.com:
Hi,
This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.
2013-12-11 17:43:06, Sergey Muraviov sergey.k.murav...@gmail.com:
It works in expanded mode when either format option is set to wrapped
(\pset format wrapped), or we have no pager, or pager doesn't chop long
lines (so you can still use the trick).
I do not like this logic on the IsWrappingNeeded function. It does not
seems right to check the environment variables for less. It would be hard
to explain this behavior to the users. It is better to make this only
the behavior of the wrapped format in expanded mode, in my opinion.
You are right. This logic is too complicated.
New patch works with PRINT_WRAPPED option only.
{
if (opt_border 2)
fprintf(fout, %s\n,
dlineptr[line_count].ptr);
else
fprintf(fout, %-s%*s
%s\n, dlineptr[line_count].ptr,
dwidth -
dlineptr[line_count].width, ,
dformat-rightvrule);
}
Is it necessary to keep this old print line code? It seems to me the new
code works well on (dlineptr[line_count].width = dwidth) condition.
New code doesn't work with empty strings but I've done minor optimization
for this case.
--
Best regards,
Sergey Muraviov
From 48ba7ed8c5ff82cdc1c912ff9ac966962f18ce54 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Sun, 16 Feb 2014 20:00:10 +0400
Subject: [PATCH] Now patch works with PRINT_WRAPPED option only
---
src/bin/psql/print.c | 79 ++--
1 file changed, 71 insertions(+), 8 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..d7bf412 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,6 +1234,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+ if (cont-opt-format == PRINT_WRAPPED)
+ {
+ int output_columns = 0;
+ /*
+ * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+ */
+ if (cont-opt-columns 0)
+ output_columns = cont-opt-columns;
+ else
+ {
+ if (cont-opt-env_columns 0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+ else
+ {
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+ output_columns = screen_size.ws_col;
+ }
+#endif
+ }
+
+ output_columns -= hwidth;
+
+ if (opt_border == 0)
+ output_columns -= 1;
+ else
+ {
+ output_columns -= 3; /* -+- */
+
+ if (opt_border 1)
+output_columns -= 4; /* +--+ */
+ }
+
+ if ((output_columns 0) (dwidth output_columns))
+ dwidth = output_columns;
+ }
+
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
@@ -1292,20 +1331,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
else
fputc(' ', fout);
- if (!dcomplete)
+ if ((!dcomplete) (dlineptr[line_count].width 0))
{
-if (opt_border 2)
- fprintf(fout, %s\n, dlineptr[line_count].ptr);
-else
- fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
- dwidth - dlineptr[line_count].width, ,
- dformat-rightvrule);
+int offset = 0;
+int chars_to_output = dlineptr[line_count].width;
+while (chars_to_output 0)
+{
+ int target_width, bytes_to_output;
+ if (offset 0)
+ {
+ if (opt_border == 2)
+ fprintf(fout, %s , dformat-leftvrule);
+
+ fprintf(fout, %*s, hwidth, );
+
+ if (opt_border 0)
+ fprintf(fout, %s , dformat-midvrule);
+ else
+ fputc(' ', fout);
+ }
+
+ target_width = dwidth;
+ bytes_to_output = strlen_max_width(dlineptr[line_count].ptr + offset,
+ target_width, encoding);
+ fputnbytes(fout, (char *)(dlineptr[line_count].ptr + offset), bytes_to_output);
+ chars_to_output -= target_width;
+ offset += bytes_to_output;
+
+ if (opt_border 2)
+ fputc('\n', fout);
+ else
+ fprintf(fout, %*s %s\n, dwidth - target_width, , dformat-rightvrule);
+}
if (!dlineptr[line_count + 1].ptr)
dcomplete = 1;
}
else
{
+dcomplete = 1;
if (opt_border 2)
fputc('\n', fout);
else
@@ -2175,7 +2239,6 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
/* Public functions */
//
-
/*
* PageOutput
*
--
1.8.5.3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Hi,
This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.
2013-12-11 17:43:06, Sergey Muraviov sergey.k.murav...@gmail.com:
It works in expanded mode when either format option is set to wrapped
(\pset format wrapped), or we have no pager, or pager doesn't chop long
lines (so you can still use the trick).
I do not like this logic on the IsWrappingNeeded function. It does not
seems right to check the environment variables for less. It would be hard
to explain this behavior to the users. It is better to make this only
the behavior of the wrapped format in expanded mode, in my opinion.
{
if (opt_border 2)
fprintf(fout, %s\n,
dlineptr[line_count].ptr);
else
fprintf(fout, %-s%*s %s\n,
dlineptr[line_count].ptr,
dwidth -
dlineptr[line_count].width, ,
dformat-rightvrule);
}
Is it necessary to keep this old print line code? It seems to me the new
code works well on (dlineptr[line_count].width = dwidth) condition.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Please fix this: src/bin/psql/print.c:1269: trailing whitespace. src/bin/psql/print.c:1351: trailing whitespace. src/bin/psql/print.c:1359: trailing whitespace. src/bin/psql/print.c:1364: trailing whitespace. src/bin/psql/print.c:2263: trailing whitespace. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
fixed
2013/12/24 Peter Eisentraut pete...@gmx.net
Please fix this:
src/bin/psql/print.c:1269: trailing whitespace.
src/bin/psql/print.c:1351: trailing whitespace.
src/bin/psql/print.c:1359: trailing whitespace.
src/bin/psql/print.c:1364: trailing whitespace.
src/bin/psql/print.c:2263: trailing whitespace.
--
Best regards,
Sergey Muraviov
From be9f01777599dc5e84c417e5cae56459677a88d4 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Wed, 11 Dec 2013 20:17:26 +0400
Subject: [PATCH 1/2] wrapped tables in expanded mode
---
src/bin/psql/print.c | 123 ---
1 file changed, 118 insertions(+), 5 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 736225c..4c37f7d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -124,6 +124,7 @@ const printTextFormat pg_utf8format =
/* Local functions */
static int strlen_max_width(unsigned char *str, int *target_width, int encoding);
+static bool IsWrappingNeeded(const printTableContent *cont, bool is_pager);
static void IsPagerNeeded(const printTableContent *cont, const int extra_lines, bool expanded,
FILE **fout, bool *is_pager);
@@ -1234,6 +1235,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+ if (IsWrappingNeeded(cont, is_pager))
+ {
+ int output_columns = 0;
+ /*
+ * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+ */
+ if (cont-opt-columns 0)
+ output_columns = cont-opt-columns;
+ else
+ {
+ if (cont-opt-env_columns 0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+ else
+ {
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+ output_columns = screen_size.ws_col;
+ }
+#endif
+ }
+
+ output_columns -= hwidth;
+
+ if (opt_border == 0)
+ output_columns -= 1;
+ else
+ {
+ output_columns -= 3; /* -+- */
+
+ if (opt_border 1)
+output_columns -= 4; /* +--+ */
+ }
+
+ if ((output_columns 0) (dwidth output_columns))
+ dwidth = output_columns;
+ }
+
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
@@ -1294,12 +1334,49 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
if (!dcomplete)
{
-if (opt_border 2)
- fprintf(fout, %s\n, dlineptr[line_count].ptr);
+if (dlineptr[line_count].width dwidth)
+{
+ int offset = 0;
+ int chars_to_output = dlineptr[line_count].width;
+ while (chars_to_output 0)
+ {
+ int target_width, bytes_to_output;
+
+ if (offset 0)
+ {
+ if (opt_border == 2)
+fprintf(fout, %s , dformat-leftvrule);
+
+ fprintf(fout, %*s, hwidth, );
+
+ if (opt_border 0)
+fprintf(fout, %s , dformat-midvrule);
+ else
+fputc(' ', fout);
+ }
+
+ target_width = dwidth;
+ bytes_to_output = strlen_max_width(dlineptr[line_count].ptr + offset,
+ target_width, encoding);
+ fputnbytes(fout, (char *)(dlineptr[line_count].ptr + offset), bytes_to_output);
+ chars_to_output -= target_width;
+ offset += bytes_to_output;
+
+ if (opt_border 2)
+ fputc('\n', fout);
+ else
+ fprintf(fout, %*s %s\n, dwidth - target_width, , dformat-rightvrule);
+ }
+}
else
- fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
- dwidth - dlineptr[line_count].width, ,
- dformat-rightvrule);
+{
+ if (opt_border 2)
+ fprintf(fout, %s\n, dlineptr[line_count].ptr);
+ else
+ fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
+dwidth - dlineptr[line_count].width, ,
+dformat-rightvrule);
+}
if (!dlineptr[line_count + 1].ptr)
dcomplete = 1;
@@ -2175,6 +2252,42 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
/* Public functions */
//
+/*
+ * IsWrappingNeeded
+ *
+ * Tests if wrapping is needed
+ */
+static bool
+IsWrappingNeeded(const printTableContent *cont, bool is_pager)
+{
+ const char *pagerprog = 0,
+*less_options = 0;
+
+ if ((cont-opt-format == PRINT_WRAPPED) || (is_pager == false))
+ return true;
+
+ pagerprog = getenv(PAGER);
+ if (!pagerprog)
+ pagerprog = DEFAULT_PAGER;
+
+ if (strcmp(pagerprog, less) != 0)
+ return true;
+
+ less_options = getenv(LESS);
+ if (!less_options)
+ return true;
+/*
+ * Test for -S option
+ * Causes lines longer than the screen width to be chopped rather
+ * than folded. That is, the portion of a long line that does not
+ * fit in the screen width is not shown. The default is to fold
+ * long lines; that is, display the remainder on the next line.
+ */
+ if (strchr(less_options, 'S'))
+ return false;
+ else
+ return true;
+}
/*
* PageOutput
--
1.8.4.2
From 9c4076796386ee3062fcc51272eb3e6e9b66bb1d Mon Sep 17 00:00:00 2001
From: Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
Hello 2013/12/18 Sameer Thakur samthaku...@gmail.com On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Hi. I've improved the patch. It works in expanded mode when either format option is set to wrapped (\pset format wrapped), or we have no pager, or pager doesn't chop long lines (so you can still use the trick). Target output width is taken from either columns option (\pset columns 70), or environment variable $COLUMNS, or terminal size. And it's also compatible with any border style (\pset border 0|1|2). Here are some examples: postgres=# \x 1 postgres=# \pset format wrapped postgres=# \pset border 0 postgres=# select * from wide_table; * Record 1 value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfa sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf * Record 2 value afadsafasd fasdf asdfasd postgres=# \pset border 1 postgres=# \pset columns 70 postgres=# select * from wide_table; -[ RECORD 1 ]- value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa | df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f | sadf sad fadsf -[ RECORD 2 ]- value | afadsafasd fasdf asdfasd postgres=# \pset border 2 postgres=# \pset columns 60 postgres=# select * from wide_table; +-[ RECORD 1 ]-+ | value | afadsafasd fasdf asdfasd fsad fas df sadf sad f | | | sadf sadf sa df sadfsadfasd fsad fsa df sadf as | | | d fa sfd sadfsadf asdf sad f sadf sad fadsf | +-[ RECORD 2 ]-+ | value | afadsafasd fasdf asdfasd | +---+--+ Regards, Sergey The patch applies and compile cleanly. I tried the following \pset format wrapped \pset columns 70. Not in expanded mode select * from wide_table works fine. select * from pg_stats has problems in viewing. Is it that pg_stats can be viewed easily only in expanded mode i.e. if columns displayed are wrapped then there is no way to view results in non expanded mode? regards Sameer The problem with non expanded mode is that all column headers have to be displayed on one line. Otherwise, it is difficult to bind values to columns. And I have no idea how to solve this problem. -- Best regards, Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Hi. I've improved the patch. It works in expanded mode when either format option is set to wrapped (\pset format wrapped), or we have no pager, or pager doesn't chop long lines (so you can still use the trick). Target output width is taken from either columns option (\pset columns 70), or environment variable $COLUMNS, or terminal size. And it's also compatible with any border style (\pset border 0|1|2). Here are some examples: postgres=# \x 1 postgres=# \pset format wrapped postgres=# \pset border 0 postgres=# select * from wide_table; * Record 1 value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfa sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf * Record 2 value afadsafasd fasdf asdfasd postgres=# \pset border 1 postgres=# \pset columns 70 postgres=# select * from wide_table; -[ RECORD 1 ]- value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa | df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f | sadf sad fadsf -[ RECORD 2 ]- value | afadsafasd fasdf asdfasd postgres=# \pset border 2 postgres=# \pset columns 60 postgres=# select * from wide_table; +-[ RECORD 1 ]-+ | value | afadsafasd fasdf asdfasd fsad fas df sadf sad f | | | sadf sadf sa df sadfsadfasd fsad fsa df sadf as | | | d fa sfd sadfsadf asdf sad f sadf sad fadsf | +-[ RECORD 2 ]-+ | value | afadsafasd fasdf asdfasd | +---+--+ Regards, Sergey The patch applies and compile cleanly. I tried the following \pset format wrapped \pset columns 70. Not in expanded mode select * from wide_table works fine. select * from pg_stats has problems in viewing. Is it that pg_stats can be viewed easily only in expanded mode i.e. if columns displayed are wrapped then there is no way to view results in non expanded mode? regards Sameer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
Hi.
I've improved the patch.
It works in expanded mode when either format option is set to wrapped
(\pset format wrapped), or we have no pager, or pager doesn't chop long
lines (so you can still use the trick).
Target output width is taken from either columns option (\pset columns 70),
or environment variable $COLUMNS, or terminal size.
And it's also compatible with any border style (\pset border 0|1|2).
Here are some examples:
postgres=# \x 1
postgres=# \pset format wrapped
postgres=# \pset border 0
postgres=# select * from wide_table;
* Record 1
value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfsadfa
sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
* Record 2
value afadsafasd fasdf asdfasd
postgres=# \pset border 1
postgres=# \pset columns 70
postgres=# select * from wide_table;
-[ RECORD 1 ]-
value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa
| df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f
| sadf sad fadsf
-[ RECORD 2 ]-
value | afadsafasd fasdf asdfasd
postgres=# \pset border 2
postgres=# \pset columns 60
postgres=# select * from wide_table;
+-[ RECORD 1 ]-+
| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f |
| | sadf sadf sa df sadfsadfasd fsad fsa df sadf as |
| | d fa sfd sadfsadf asdf sad f sadf sad fadsf |
+-[ RECORD 2 ]-+
| value | afadsafasd fasdf asdfasd |
+---+--+
Regards,
Sergey
2013/12/10 Jeff Janes jeff.ja...@gmail.com
On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
Hi.
Psql definitely have a problem with displaying wide tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.
I get compiler warnings:
print.c: In function 'print_aligned_vertical':
print.c:1238: warning: ISO C90 forbids mixed declarations and code
print.c: In function 'print_aligned_vertical':
print.c:1238: warning: ISO C90 forbids mixed declarations and code
But I really like this and am already benefiting from it. No point in
having the string of hyphens between every record wrap to be 30 lines long
just because one field somewhere down the list does so. And configuring
the pager isn't much of a solution because the pager doesn't know that the
hyphens are semantically different than the other stuff getting thrown at
it.
Cheers,
Jeff
--
Best regards,
Sergey Muraviov
From be9f01777599dc5e84c417e5cae56459677a88d4 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Wed, 11 Dec 2013 20:17:26 +0400
Subject: [PATCH] wrapped tables in expanded mode
---
src/bin/psql/print.c | 123 ---
1 file changed, 118 insertions(+), 5 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 736225c..4c37f7d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -124,6 +124,7 @@ const printTextFormat pg_utf8format =
/* Local functions */
static int strlen_max_width(unsigned char *str, int *target_width, int encoding);
+static bool IsWrappingNeeded(const printTableContent *cont, bool is_pager);
static void IsPagerNeeded(const printTableContent *cont, const int extra_lines, bool expanded,
FILE **fout, bool *is_pager);
@@ -1234,6 +1235,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+ if (IsWrappingNeeded(cont, is_pager))
+ {
+ int output_columns = 0;
+ /*
+ * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+ */
+ if (cont-opt-columns 0)
+ output_columns = cont-opt-columns;
+ else
+ {
+ if (cont-opt-env_columns 0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+ else
+ {
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+ output_columns = screen_size.ws_col;
+ }
+#endif
+ }
+
+ output_columns -= hwidth;
+
+ if (opt_border == 0)
+ output_columns -= 1;
+ else
+ {
+ output_columns -= 3; /* -+- */
+
+ if (opt_border 1)
+output_columns -= 4; /* +--+ */
+ }
+
+ if ((output_columns 0) (dwidth output_columns))
+ dwidth = output_columns;
+ }
+
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
@@ -1294,12 +1334,49 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
if (!dcomplete)
{
-if (opt_border 2)
- fprintf(fout, %s\n, dlineptr[line_count].ptr);
+if (dlineptr[line_count].width dwidth)
+{
+ int offset = 0;
+ int chars_to_output = dlineptr[line_count].width;
+ while (chars_to_output 0)
+ {
+ int target_width, bytes_to_output;
+
+ if (offset 0)
+
Re: [HACKERS] Problem with displaying wide tables in psql
On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Hi. Psql definitely have a problem with displaying wide tables. Even in expanded mode, they look horrible. So I tried to solve this problem. I get compiler warnings: print.c: In function 'print_aligned_vertical': print.c:1238: warning: ISO C90 forbids mixed declarations and code print.c: In function 'print_aligned_vertical': print.c:1238: warning: ISO C90 forbids mixed declarations and code But I really like this and am already benefiting from it. No point in having the string of hyphens between every record wrap to be 30 lines long just because one field somewhere down the list does so. And configuring the pager isn't much of a solution because the pager doesn't know that the hyphens are semantically different than the other stuff getting thrown at it. Cheers, Jeff
Re: [HACKERS] Problem with displaying wide tables in psql
On Thu, Dec 5, 2013 at 1:09 AM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: And my patch affects the row view only. To help us avoid forgetting about this patch, please add it here: https://commitfest.postgresql.org/action/commitfest_view/open -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with displaying wide tables in psql
On Wed, Dec 4, 2013 at 11:20 AM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Thank you for this trick. It would be nice if this trick was documented. However, with the pager I can't see wide value on one screen, select and copy it entirely. And I have to press many keys to find the necessary part of the value. There is no such problems with the patch. I think the solution is to provide proposed behaviour as an option. -- With best regards, Alexander Korotkov.
Re: [HACKERS] Problem with displaying wide tables in psql
Hello postgres=# \pset format wrapped Output format (format) is wrapped. postgres=# select 'afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf'; ?column? - afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf a. .sdf sad f sadf sad fadsf (1 row) It works as expected but it is not supported for row view. So any fix of this mode should be nice Regards Pavel 2013/12/4 Sergey Muraviov sergey.k.murav...@gmail.com Thank you for this trick. It would be nice if this trick was documented. However, with the pager I can't see wide value on one screen, select and copy it entirely. And I have to press many keys to find the necessary part of the value. There is no such problems with the patch. 2013/12/3 Pavel Stehule pavel.steh...@gmail.com Hello do you know a pager less trick http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html Regards Pavel Stehule 2013/12/3 Sergey Muraviov sergey.k.murav...@gmail.com Hi. Psql definitely have a problem with displaying wide tables. Even in expanded mode, they look horrible. So I tried to solve this problem. Before the patch: postgres=# \x 1 Expanded display (expanded) is on. postgres=# \pset border 2 Border style (border) is 2. postgres=# select * from pg_stats; +-[ RECORD 1 ]---+--
Re: [HACKERS] Problem with displaying wide tables in psql
And my patch affects the row view only.
postgres=# \x 1
postgres=# create table wide_table (value text);
postgres=# insert into wide_table values ('afadsafasd fasdf asdfasd fsad
fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd
sadfsadf asdf sad f sadf sad fadsf');
postgres=# insert into wide_table values ('afadsafasd fasdf asdfasd');
postgres=# select * from wide_table;
-[ RECORD 1
]---
---
value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfsad
fasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
-[ RECORD 2
]---
---
value | afadsafasd fasdf
If we add a new column to this table and put the border on, we can see that
all values in the table have the same width.
postgres=# alter table wide_table add column id integer;
postgres=# \pset border 2
postgres=# select * from wide_table;
+-[ RECORD 1
]--
--+
| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfs
adfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf |
| id|
|
+-[ RECORD 2
]--
--+
| value | afadsafasd fasdf asdfasd
|
| id|
|
+---+---
--+
My patch tries to solve these problems:
-[ RECORD 1
]---
value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfsad
fasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
-[ RECORD 2
]---
value | afadsafasd fasdf asdfasd
and
+-[ RECORD 1
]-+
| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfs
adfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
|
| id|
|
+-[ RECORD 2
]-+
| value | afadsafasd fasdf asdfasd
|
| id|
|
+---+--+
Regards
2013/12/4 Pavel Stehule pavel.steh...@gmail.com
Hello
postgres=# \pset format wrapped
Output format (format) is wrapped.
postgres=# select 'afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf
sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf
sad fadsf';
?column?
-
afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf a.
.sdf sad f sadf sad fadsf
(1 row)
It works as expected
but it is not supported for row view. So any fix of this mode should be
nice
Regards
Pavel
2013/12/4 Sergey Muraviov sergey.k.murav...@gmail.com
Thank you for this trick.
It would be nice if this trick was documented.
However, with the pager I can't see wide value on one screen, select and
copy it entirely.
And I have to press many keys to find the necessary part of the value.
There is no such problems with the patch.
2013/12/3 Pavel Stehule pavel.steh...@gmail.com
Hello
do you know a pager less trick
http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html
Regards
Pavel Stehule
2013/12/3 Sergey Muraviov sergey.k.murav...@gmail.com
Hi.
Psql definitely have a problem with displaying wide tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.
Before the patch:
postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;
+-[ RECORD 1
]---+--
[HACKERS] Problem with displaying wide tables in psql
Hi. Psql definitely have a problem with displaying wide tables. Even in expanded mode, they look horrible. So I tried to solve this problem. Before the patch: postgres=# \x 1 Expanded display (expanded) is on. postgres=# \pset border 2 Border style (border) is 2. postgres=# select * from pg_stats; +-[ RECORD 1 ]---+-- --+ | schemaname | pg_catalog | | tablename | pg_proc ... and after: +-[ RECORD 1 ]---+-+ | schemaname | pg_catalog | | tablename | pg_proc | | attname| proname | | inherited | f | | null_frac | 0 | | avg_width | 64 | | n_distinct | -0.823159 | | most_common_vals |
Re: [HACKERS] Problem with displaying wide tables in psql
Hello do you know a pager less trick http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html Regards Pavel Stehule 2013/12/3 Sergey Muraviov sergey.k.murav...@gmail.com Hi. Psql definitely have a problem with displaying wide tables. Even in expanded mode, they look horrible. So I tried to solve this problem. Before the patch: postgres=# \x 1 Expanded display (expanded) is on. postgres=# \pset border 2 Border style (border) is 2. postgres=# select * from pg_stats; +-[ RECORD 1 ]---+-- --+ | schemaname | pg_catalog | | tablename | pg_proc ... and after: +-[ RECORD 1 ]---+-+ | schemaname |
Re: [HACKERS] Problem with displaying wide tables in psql
Thank you for this trick. It would be nice if this trick was documented. However, with the pager I can't see wide value on one screen, select and copy it entirely. And I have to press many keys to find the necessary part of the value. There is no such problems with the patch. 2013/12/3 Pavel Stehule pavel.steh...@gmail.com Hello do you know a pager less trick http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html Regards Pavel Stehule 2013/12/3 Sergey Muraviov sergey.k.murav...@gmail.com Hi. Psql definitely have a problem with displaying wide tables. Even in expanded mode, they look horrible. So I tried to solve this problem. Before the patch: postgres=# \x 1 Expanded display (expanded) is on. postgres=# \pset border 2 Border style (border) is 2. postgres=# select * from pg_stats; +-[ RECORD 1 ]---+-- --+ | schemaname |
