Re: [HACKERS] printing table in asciidoc with psql
On Tue, Mar 31, 2015 at 05:06:49PM -0400, Bruce Momjian wrote: Uh, you broke asciidoctor 1.5.2. ;-) LOL I installed the Asciidoctor Firefox plugin: Asciidoctor has confirmed they have a bug and hope to fix it in their next release: http://discuss.asciidoctor.org/Problem-with-table-heading-ending-in-a-pipe-tp2902p2916.html -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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] printing table in asciidoc with psql
On Wed, Mar 25, 2015 at 09:12:41AM -0400, Bruce Momjian wrote: On Wed, Mar 25, 2015 at 09:37:08PM +0900, Michael Paquier wrote: On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian br...@momjian.us wrote: On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, OK, fixed. Thanks for the testing. Patch attached. New output: This time things look good from my side. I have played with this patch some time, testing some crazy scenarios and I have not found problems. That's cool stuff, thanks! Wow, thanks. I never would have gotten here without your help. Slightly updated patch attached and applied. I moved asciidoc after HTML in the list, rather than at the end. Thanks for everyone's hard work on this. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a33e460..1f29615 *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2090,2096 para Sets the output format to one of literalunaligned/literal, literalaligned/literal, literalwrapped/literal, ! literalhtml/literal, literallatex/literal (uses literaltabular/literal), literallatex-longtable/literal, or literaltroff-ms/literal. --- 2090,2096 para Sets the output format to one of literalunaligned/literal, literalaligned/literal, literalwrapped/literal, ! literalhtml/literal, literalasciidoc/literal, literallatex/literal (uses literaltabular/literal), literallatex-longtable/literal, or literaltroff-ms/literal. *** lo_import 152801 *** 2119,2125 /para para ! The literalhtml/, literallatex/, literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up --- 2119,2125 /para para ! The literalhtml/, literalasciidoc/, literallatex/, literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index e64c033..916f1c6 *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2249,2254 --- 2249,2257 case PRINT_HTML: return html; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; case PRINT_LATEX: return latex; break; *** do_pset(const char *param, const char *v *** 2325,2330 --- 2328,2335 popt-topt.format = PRINT_WRAPPED; else if (pg_strncasecmp(html, value, vallen) == 0) popt-topt.format = PRINT_HTML; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else if (pg_strncasecmp(latex, value, vallen) == 0) popt-topt.format = PRINT_LATEX; else if (pg_strncasecmp(latex-longtable, value, vallen) == 0) *** do_pset(const char *param, const char *v *** 2333,2339 popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2338,2344 popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, asciidoc, latex, troff-ms\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index 2da444b..f58f5e5 *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); ! fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style
Re: [HACKERS] printing table in asciidoc with psql
On 31 March 2015 at 16:35, Bruce Momjian br...@momjian.us wrote: On Wed, Mar 25, 2015 at 09:12:41AM -0400, Bruce Momjian wrote: On Wed, Mar 25, 2015 at 09:37:08PM +0900, Michael Paquier wrote: On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian br...@momjian.us wrote: On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, OK, fixed. Thanks for the testing. Patch attached. New output: This time things look good from my side. I have played with this patch some time, testing some crazy scenarios and I have not found problems. That's cool stuff, thanks! Wow, thanks. I never would have gotten here without your help. Slightly updated patch attached and applied. I moved asciidoc after HTML in the list, rather than at the end. Thanks for everyone's hard work on this. I think I done gone broke it: CREATE TABLE | 3^.||moo|hello, (stuff int, |.^hje|| text); INSERT INTO | 3^.||moo|hello, VALUES (2,'hello'); Output: [options=header,cols=l,l,frame=none] | ^l|stuff ^l|\|.^hje\|\| |2 |hello | (1 row) This results in: table class=tableblock frame-none grid-all spread colgroup col style=width: 50%; col style=width: 50%; /colgroup thead tr th class=tableblock halign-center valign-topstuff/th th class=tableblock halign-center valign-top|amp;.^hje||2/th /tr /thead /table Using asciidoctor 1.5.2. -- Thom
Re: [HACKERS] printing table in asciidoc with psql
On Tue, Mar 31, 2015 at 05:25:48PM +0100, Thom Brown wrote: Slightly updated patch attached and applied. I moved asciidoc after HTML in the list, rather than at the end. Thanks for everyone's hard work on this. I think I done gone broke it: CREATE TABLE | 3^.||moo|hello, (stuff int, |.^hje|| text); INSERT INTO | 3^.||moo|hello, VALUES (2,'hello'); Output: [options=header,cols=l,l,frame=none] | ^l|stuff ^l|\|.^hje\|\| |2 |hello | Uh, you broke asciidoctor 1.5.2. ;-) LOL I installed the Asciidoctor Firefox plugin: https://addons.mozilla.org/en-US/firefox/addon/asciidoctorjs-live-preview/ and was able to see that asciidoctor sucks in the next row's first cell value when the _heading_ ends with an escaped pipe, e.g. this: [options=header,cols=l,l,frame=none] | ^l|stuff ^l|abc\|X |2 |hello\| |3 |hello | yields a correct HTML heading of: stuff abc|X which is good, but if you remove the X from the asciidoc heading, the HTML output heading is: stuff abc|2 The X is gone, but the 2 from the first data row is now in the heading, and the first and only data row is now: hello|3 hello I can't add a trailing pipe to the header line because it breaks output in https://asciidoclive.com/ . I have reported this on the asciidoc discussion list: http://discuss.asciidoctor.org/Problem-with-table-heading-ending-in-a-pipe-td2902.html -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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] printing table in asciidoc with psql
On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, OK, fixed. Thanks for the testing. Patch attached. New output: --- test= \pset format asciidoc Output format is asciidoc. test= \t Tuples only is on. test= table 5 2.2+^.^ ; [cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a637001..82a91ec *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, or ! literaltroff-ms/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para --- 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, ! literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para *** lo_import 152801 *** 2120,2126 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be --- 2120,2127 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, literaltroff-ms/, ! and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index 7c9f28d..a96f0ef *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2257,2262 --- 2257,2265 case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } *** do_pset(const char *param, const char *v *** 2330,2338 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2333,2343 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index ac0dc27..93a517e *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); ! fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style [ascii, old-ascii, unicode]\n)); fprintf(output, _( null set the string to be printed in place of a null value\n)); --- 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field
Re: [HACKERS] printing table in asciidoc with psql
On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian br...@momjian.us wrote: On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, OK, fixed. Thanks for the testing. Patch attached. New output: This time things look good from my side. I have played with this patch some time, testing some crazy scenarios and I have not found problems. That's cool stuff, thanks! -- 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] printing table in asciidoc with psql
On Wed, Mar 25, 2015 at 09:37:08PM +0900, Michael Paquier wrote: On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian br...@momjian.us wrote: On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, OK, fixed. Thanks for the testing. Patch attached. New output: This time things look good from my side. I have played with this patch some time, testing some crazy scenarios and I have not found problems. That's cool stuff, thanks! Wow, thanks. I never would have gotten here without your help. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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] printing table in asciidoc with psql
On Wed, Mar 25, 2015 at 4:52 AM, Bruce Momjian br...@momjian.us wrote: On Tue, Mar 24, 2015 at 11:15:33AM +0900, Michael Paquier wrote: On Tue, Mar 24, 2015 at 8:44 AM, Bruce Momjian wrote: Notice the added 'l' next to the ''. Updated patch attached. Any other issues? Ah, right. That's a good catch and your patch fixes the issue. Still, there are problems with the tuple-only mode and the expanded mode. For example using this example (wanted over-complicated): create table 5 2.2+^.^ (5 2.2+^.^ text, 4 2.2+^.^ text); insert into 5 2.2+^.^ values ('5 2.2+^.^', '4 2.2+^.^'); insert into 5 2.2+^.^ values ('2 2.2+^.^', '3 2.2+^.^'); \pset format asciidoc OK, all fixed. Some of the bugs were original, but at least one was introduced by me. Patch attached. New output: test= \x Expanded display is off. test= \t Tuples only is on. test= table 5 2.2+^.^ ; [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Hm. This is still incorrect. You should remove options=header here or the first tuple is treated as a header in the case non-expanded/tuple-only. Your patch removes correctly the header for the expanded/tuple-only case though. Regards, -- 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] printing table in asciidoc with psql
On Tue, Mar 24, 2015 at 11:15:33AM +0900, Michael Paquier wrote: On Tue, Mar 24, 2015 at 8:44 AM, Bruce Momjian wrote: Notice the added 'l' next to the ''. Updated patch attached. Any other issues? Ah, right. That's a good catch and your patch fixes the issue. Still, there are problems with the tuple-only mode and the expanded mode. For example using this example (wanted over-complicated): create table 5 2.2+^.^ (5 2.2+^.^ text, 4 2.2+^.^ text); insert into 5 2.2+^.^ values ('5 2.2+^.^', '4 2.2+^.^'); insert into 5 2.2+^.^ values ('2 2.2+^.^', '3 2.2+^.^'); \pset format asciidoc OK, all fixed. Some of the bugs were original, but at least one was introduced by me. Patch attached. New output: --- test= \pset format asciidoc Output format is asciidoc. test= table 5 2.2+^.^ ; [options=header,cols=l,l,frame=none] | ^l|5 2.2+^.^ ^l|4 2.2+^.^ |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | (2 rows) test= \x Expanded display is on. test= table 5 2.2+^.^ ; [cols=h,l,frame=none] | 2+^|Record 1 l|5 2.2+^.^ l|5 2.2+^.^ l|4 2.2+^.^ l|4 2.2+^.^ 2+^|Record 2 l|5 2.2+^.^ l|2 2.2+^.^ l|4 2.2+^.^ l|3 2.2+^.^ | test= \x Expanded display is off. test= \t Tuples only is on. test= table 5 2.2+^.^ ; [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | test= \x Expanded display is on. test= table 5 2.2+^.^ ; [cols=h,l,frame=none] | 2+| l|5 2.2+^.^ l|5 2.2+^.^ l|4 2.2+^.^ l|4 2.2+^.^ 2+| l|5 2.2+^.^ l|2 2.2+^.^ l|4 2.2+^.^ l|3 2.2+^.^ | -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a637001..82a91ec *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, or ! literaltroff-ms/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para --- 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, ! literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para *** lo_import 152801 *** 2120,2126 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be --- 2120,2127 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, literaltroff-ms/, ! and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index 7c9f28d..a96f0ef *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2257,2262 --- 2257,2265 case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } *** do_pset(const char *param, const char *v *** 2330,2338 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2333,2343 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index ac0dc27..93a517e *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded
Re: [HACKERS] printing table in asciidoc with psql
On Sun, Mar 22, 2015 at 08:06:17PM +0900, Michael Paquier wrote: I have updated the attached patch to do as you suggested. Please also test the \x output. Thanks. Indeed. If I use a specific column name like this one, I am seeing problems with the expanded mode: =# create table 5 2.2+^.^ (5 2.2+^.^ int); CREATE TABLE =# \x Expanded display is on. =# INSERT INTO 5 2.2+^.^ VALUES (1); INSERT 0 1 =# table 5 2.2+^.^; [cols=h,l,frame=none] | 2+^|Record 1 |5 2.2+^.^ |1 | In this case the record is printed like that: 5 2.2+. While it should show up like that: 5 2.2+^.^ OK, fixed. It turns out you need to specify the style on each output row ('l'/literal) so that a later data value of ^.^ is not intepreted as a horizontal/vertial alignment specification. (Wow, it sounds like I know what I am talking about. ;-) ) The new output is: test= \pset format asciidoc Output format is asciidoc. test= \x Expanded display is on. test= table 5 2.2+^.^; [cols=h,l,frame=none] | 2+^|Record 1 -- l|5 2.2+^.^ |1 | Notice the added 'l' next to the ''. Updated patch attached. Any other issues? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a637001..82a91ec *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, or ! literaltroff-ms/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para --- 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, ! literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para *** lo_import 152801 *** 2120,2126 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be --- 2120,2127 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, literaltroff-ms/, ! and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index 7c9f28d..a96f0ef *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2257,2262 --- 2257,2265 case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } *** do_pset(const char *param, const char *v *** 2330,2338 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2333,2343 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index ac0dc27..93a517e *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); ! fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); fprintf(output, _( footer enable or disable display of the
Re: [HACKERS] printing table in asciidoc with psql
On Tue, Mar 24, 2015 at 8:44 AM, Bruce Momjian wrote: Notice the added 'l' next to the ''. Updated patch attached. Any other issues? Ah, right. That's a good catch and your patch fixes the issue. Still, there are problems with the tuple-only mode and the expanded mode. For example using this example (wanted over-complicated): create table 5 2.2+^.^ (5 2.2+^.^ text, 4 2.2+^.^ text); insert into 5 2.2+^.^ values ('5 2.2+^.^', '4 2.2+^.^'); insert into 5 2.2+^.^ values ('2 2.2+^.^', '3 2.2+^.^'); \pset format asciidoc -- This prints first tuple as a header (which transforms ^.^ to . btw), 2nd as a normal row: =# table 5 2.2+^.^ ; [options=header,cols=l,l,frame=none] | |5 2.2+^.^ |4 2.2+^.^ |2 2.2+^.^ |3 2.2+^.^ | Time: 0.451 ms And with the expanded mode this has an incorrect format: =# \x Expanded display is on. =# table 5 2.2+^.^ ; [cols=h,l,frame=none] | 2| l|5 2.2+^.^ |5 2.2+^.^ l|4 2.2+^.^ |4 2.2+^.^ 2| l|5 2.2+^.^ |2 2.2+^.^ l|4 2.2+^.^ |3 2.2+^.^ | Time: 0.555 ms Regards, -- 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] printing table in asciidoc with psql
On Sun, Mar 22, 2015 at 10:09 AM, Bruce Momjian br...@momjian.us wrote: On Sat, Mar 21, 2015 at 09:20:03PM +0900, Michael Paquier wrote: This does not work: =# create table 5 2.2+^.^ (); CREATE TABLE =# \pset format asciidoc Output format is asciidoc. =# \d .List of relations [options=header,cols=l,l,l,l,frame=none] | ^l|Schema ^l|Name ^l|Type ^l|Owner |public|5 2.2+^.^|table|ioltas | (1 row) I think that we should really put additional spaces on the left side of the column separators |. For example, this line: |public|5 2.2+^.^|table|ioltas should become that: |public |5 2.2+^.^ |table |ioltas And there is no problem. I have updated the attached patch to do as you suggested. Please also test the \x output. Thanks. Indeed. If I use a specific column name like this one, I am seeing problems with the expanded mode: =# create table 5 2.2+^.^ (5 2.2+^.^ int); CREATE TABLE =# \x Expanded display is on. =# INSERT INTO 5 2.2+^.^ VALUES (1); INSERT 0 1 =# table 5 2.2+^.^; [cols=h,l,frame=none] | 2+^|Record 1 |5 2.2+^.^ |1 | In this case the record is printed like that: 5 2.2+. While it should show up like that: 5 2.2+^.^ Regards, -- 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] printing table in asciidoc with psql
On Fri, Mar 20, 2015 at 11:10 PM, Bruce Momjian wrote: I was able to fix all the reported problems with the attached patch. I used this for testing the output: https://asciidoclive.com/ Is it OK now? This does not work: =# create table 5 2.2+^.^ (); CREATE TABLE =# \pset format asciidoc Output format is asciidoc. =# \d .List of relations [options=header,cols=l,l,l,l,frame=none] | ^l|Schema ^l|Name ^l|Type ^l|Owner |public|5 2.2+^.^|table|ioltas | (1 row) I think that we should really put additional spaces on the left side of the column separators |. For example, this line: |public|5 2.2+^.^|table|ioltas should become that: |public |5 2.2+^.^ |table |ioltas And there is no problem. Regards, -- 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] printing table in asciidoc with psql
On Sat, Mar 21, 2015 at 09:20:03PM +0900, Michael Paquier wrote: This does not work: =# create table 5 2.2+^.^ (); CREATE TABLE =# \pset format asciidoc Output format is asciidoc. =# \d .List of relations [options=header,cols=l,l,l,l,frame=none] | ^l|Schema ^l|Name ^l|Type ^l|Owner |public|5 2.2+^.^|table|ioltas | (1 row) I think that we should really put additional spaces on the left side of the column separators |. For example, this line: |public|5 2.2+^.^|table|ioltas should become that: |public |5 2.2+^.^ |table |ioltas And there is no problem. I have updated the attached patch to do as you suggested. Please also test the \x output. Thanks. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a637001..82a91ec *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, or ! literaltroff-ms/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para --- 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, ! literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para *** lo_import 152801 *** 2120,2126 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be --- 2120,2127 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, literaltroff-ms/, ! and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index 7c9f28d..a96f0ef *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2257,2262 --- 2257,2265 case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } *** do_pset(const char *param, const char *v *** 2330,2338 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2333,2343 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index ac0dc27..93a517e *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); ! fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style [ascii, old-ascii, unicode]\n)); fprintf(output, _( null set the string to be printed in place of a null value\n)); --- 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); !
Re: [HACKERS] printing table in asciidoc with psql
On Wed, Dec 3, 2014 at 03:52:30PM +0900, Michael Paquier wrote: I see a trailing spaces, but I don't see a described effect. Please, can you send some more specific test case? This formatting problem is trivial to reproduce: =# create table foo (); CREATE TABLE Time: 9.826 ms =# \d .List of relations [options=header,cols=l,l, l,l,frame=none] | ^l| Schema ^l| Name ^l| Type ^l| Owner | public | foo | table | ioltas | (1 row) I just tested this patch, and yes I agree with Alvaro that it would be good to minimize the extra spaces around the table separators '|'. Now we need to be careful as well, and I think that we should just remove the separators on the right of the separators as cells values controlling for example spans would result in incorrect output, stuff like that: 5 2.2+^.^ 9 2+ Also, something a bit surprising is that this format produces always one newline for each command, for example in the case of a DDL: =# create table foo (); CREATE TABLE I think that this extra space should be removed as well, no? This patch has been marked as Waiting on Author for a couple of weeks, and the problems mentioned before have not been completely addressed, hence marking this patch as returned with feedback. It would be nice to see progress for the next CF. I was able to fix all the reported problems with the attached patch. I used this for testing the output: https://asciidoclive.com/ Is it OK now? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index a637001..82a91ec *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** lo_import 152801 *** 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, or ! literaltroff-ms/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para --- 2092,2099 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), ! literallatex-longtable/literal, ! literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para *** lo_import 152801 *** 2120,2126 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, and literaltroff-ms/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be --- 2120,2127 para The literalhtml/, literallatex/, ! literallatex-longtable/literal, literaltroff-ms/, ! and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c new file mode 100644 index 7c9f28d..a96f0ef *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** _align2string(enum printFormat in) *** 2257,2262 --- 2257,2265 case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } *** do_pset(const char *param, const char *v *** 2330,2338 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); return false; } --- 2333,2343 popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { ! psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c new file mode 100644 index ac0dc27..93a517e *** a/src/bin/psql/help.c --- b/src/bin/psql/help.c *** helpVariables(unsigned short int pager) *** 351,357 fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n));
Re: [HACKERS] printing table in asciidoc with psql
On Mon, Nov 17, 2014 at 7:48 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2014-11-07 22:37 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com: I did \o /tmp/tst, then \dS create table eh | oh (); \dS and then filtered the output file to HTML. The CREATE TABLE tag ended up in the same line as the title of the following table. I think there's a newline is missing somewhere. The good news is that the | in the table name was processed correctly; but I noticed that the table title is not using the escaped print, so I would imagine that if I put a | in the title, things would go wrong. (I don't know how to put titles on tables other than editing the hardcoded titles for \ commands in psql). Another thing is that spaces around the | seem gratuituous and produce bad results. I tried select * from pg_class which results in a very wide table, and then the HTML output contains some cells with the values in the second line; this makes all rows taller than they must be, because some cells use the first line and other cells in the same row use the second line for the text. I hand-edited the asciidoc and removed the spaces around | which makes the result nicer. (Maybe removing the trailing space is enough.) I see a trailing spaces, but I don't see a described effect. Please, can you send some more specific test case? This formatting problem is trivial to reproduce: =# create table foo (); CREATE TABLE Time: 9.826 ms =# \d .List of relations [options=header,cols=l,l, l,l,frame=none] | ^l| Schema ^l| Name ^l| Type ^l| Owner | public | foo | table | ioltas | (1 row) I just tested this patch, and yes I agree with Alvaro that it would be good to minimize the extra spaces around the table separators '|'. Now we need to be careful as well, and I think that we should just remove the separators on the right of the separators as cells values controlling for example spans would result in incorrect output, stuff like that: 5 2.2+^.^ 9 2+ Also, something a bit surprising is that this format produces always one newline for each command, for example in the case of a DDL: =# create table foo (); CREATE TABLE I think that this extra space should be removed as well, no? This patch has been marked as Waiting on Author for a couple of weeks, and the problems mentioned before have not been completely addressed, hence marking this patch as returned with feedback. It would be nice to see progress for the next CF. Regards, -- 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] printing table in asciidoc with psql
On Wed, Dec 3, 2014 at 3:52 PM, Michael Paquier michael.paqu...@gmail.com wrote: This patch has been marked as Waiting on Author for a couple of weeks, and the problems mentioned before have not been completely addressed, hence marking this patch as returned with feedback. It would be nice to see progress for the next CF. Btw, here is a resource showing table formatting in asciidoc: http://asciidoc.org/newtables.html -- 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] printing table in asciidoc with psql
Hi 2014-11-07 22:37 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com: I did \o /tmp/tst, then \dS create table eh | oh (); \dS and then filtered the output file to HTML. The CREATE TABLE tag ended up in the same line as the title of the following table. I think there's a newline is missing somewhere. The good news is that the | in the table name was processed correctly; but I noticed that the table title is not using the escaped print, so I would imagine that if I put a | in the title, things would go wrong. (I don't know how to put titles on tables other than editing the hardcoded titles for \ commands in psql). Another thing is that spaces around the | seem gratuituous and produce bad results. I tried select * from pg_class which results in a very wide table, and then the HTML output contains some cells with the values in the second line; this makes all rows taller than they must be, because some cells use the first line and other cells in the same row use the second line for the text. I hand-edited the asciidoc and removed the spaces around | which makes the result nicer. (Maybe removing the trailing space is enough.) I see a trailing spaces, but I don't see a described effect. Please, can you send some more specific test case? I fixed a status view and removing trailing spaces Regards Pavel -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services commit 76e033f3a287115f15f249c657b544c148e2efd2 Author: Pavel Stehule pavel.steh...@gooddata.com Date: Sun Nov 16 23:38:46 2014 +0100 every table is in own paragraph diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index e7fcc73..cd64b88 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2092,8 +2092,8 @@ lo_import 152801 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), - literallatex-longtable/literal, or - literaltroff-ms/literal. + literallatex-longtable/literal, + literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para @@ -2120,7 +2120,8 @@ lo_import 152801 para The literalhtml/, literallatex/, - literallatex-longtable/literal, and literaltroff-ms/ + literallatex-longtable/literal, literaltroff-ms/, + and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 26089352..e00e47b 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -2248,6 +2248,9 @@ _align2string(enum printFormat in) case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } @@ -2321,9 +2324,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { - psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); + psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c index 66d80b5..ea8b9c1 100644 --- a/src/bin/psql/common.c +++ b/src/bin/psql/common.c @@ -858,6 +858,10 @@ PrintQueryStatus(PGresult *results) html_escaped_print(PQcmdStatus(results), pset.queryFout); fputs(/p\n, pset.queryFout); } + else if (pset.popt.topt.format == PRINT_ASCIIDOC) + { + fprintf(pset.queryFout, \n%s\n, PQcmdStatus(results)); + } else fprintf(pset.queryFout, %s\n, PQcmdStatus(results)); } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c index ae5fe88..b14b313 100644 --- a/src/bin/psql/help.c +++ b/src/bin/psql/help.c @@ -351,7 +351,7 @@ helpVariables(unsigned short int pager) fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); - fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); + fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n));
Re: [HACKERS] printing table in asciidoc with psql
Hi I can fix reported bugs today or tomorrow Regards Pavel 2014-11-14 21:00 GMT+01:00 Szymon Guz mabew...@gmail.com: On 14 November 2014 20:57, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Is anyone going to submit a new version of this patch? Hi Alvaro, due to family issues I will not be able to work on it for the next 10 days. regards, Szymon
Re: [HACKERS] printing table in asciidoc with psql
On 14 November 2014 20:57, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Is anyone going to submit a new version of this patch? Hi Alvaro, due to family issues I will not be able to work on it for the next 10 days. regards, Szymon
Re: [HACKERS] printing table in asciidoc with psql
I did \o /tmp/tst, then \dS create table eh | oh (); \dS and then filtered the output file to HTML. The CREATE TABLE tag ended up in the same line as the title of the following table. I think there's a newline is missing somewhere. The good news is that the | in the table name was processed correctly; but I noticed that the table title is not using the escaped print, so I would imagine that if I put a | in the title, things would go wrong. (I don't know how to put titles on tables other than editing the hardcoded titles for \ commands in psql). Another thing is that spaces around the | seem gratuituous and produce bad results. I tried select * from pg_class which results in a very wide table, and then the HTML output contains some cells with the values in the second line; this makes all rows taller than they must be, because some cells use the first line and other cells in the same row use the second line for the text. I hand-edited the asciidoc and removed the spaces around | which makes the result nicer. (Maybe removing the trailing space is enough.) -- Á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] printing table in asciidoc with psql
2014-10-29 12:23 GMT+01:00 Szymon Guz mabew...@gmail.com: On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote: Hi Szymon I found a small bug - it doesn't escape | well postgres=# select * from mytab ; a | numeric_b | c --+---+ Ahoj |10 | 2014-10-17 Hello|20 | 2014-10-18 Hi |30 | 2014-10-19 aaa| | | 2014-10-17 (4 rows) result [options=header,cols=literal,literal,literal,frame=all,grid=all] | ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++ | Ahoj | 10 | 2014-10-17 | Hello | 20 | 2014-10-18 | Hi | 30 | 2014-10-19 | aaa| | | 2014-10-17 | Next, I tested it with asciidoc and asciidoctor and I have a problem with asciidoctor - it doesn't respect aligning .. so numbers are aligned to left instead to right. When you use a option header then a formatting +++ is useless. Hi Pavel, thanks for the remarks. I've attached another version of the pach. It works a little better now, including escaping | and asciidoctor alignment support. it is fixed. Thank you. I fixed formatting - please, recheck it. I don't see any issue - it should be ready for commiter Regards Pavel thanks, Szymon commit f8ffd152aaa78ac1c96f808761680b8e593528a2 Author: Pavel Stehule pavel.steh...@gooddata.com Date: Thu Oct 30 09:02:59 2014 +0100 fix formatting diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index e7fcc73..cd64b88 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2092,8 +2092,8 @@ lo_import 152801 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), - literallatex-longtable/literal, or - literaltroff-ms/literal. + literallatex-longtable/literal, + literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para @@ -2120,7 +2120,8 @@ lo_import 152801 para The literalhtml/, literallatex/, - literallatex-longtable/literal, and literaltroff-ms/ + literallatex-longtable/literal, literaltroff-ms/, + and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 26089352..e00e47b 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -2248,6 +2248,9 @@ _align2string(enum printFormat in) case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } @@ -2321,9 +2324,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { - psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); + psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c index ae5fe88..b14b313 100644 --- a/src/bin/psql/help.c +++ b/src/bin/psql/help.c @@ -351,7 +351,7 @@ helpVariables(unsigned short int pager) fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); - fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); + fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style [ascii, old-ascii, unicode]\n)); fprintf(output, _( null set the string to be printed in place of a null value\n)); diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c index 3b3c3b7..ae98ff9 100644 --- a/src/bin/psql/print.c +++ b/src/bin/psql/print.c @@ -2475,6 +2475,216 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout) } } +/*/ +/* ASCIIDOC */ +/*/ + +static void +asciidoc_escaped_print(const char *in, FILE *fout) +{ + const char *p; + for (p = in; *p; p++) + { + switch(*p) + { + case '|': +fputs(\\|, fout); +break; + default: +
Re: [HACKERS] printing table in asciidoc with psql
On 30 October 2014 09:04, Pavel Stehule pavel.steh...@gmail.com wrote: 2014-10-29 12:23 GMT+01:00 Szymon Guz mabew...@gmail.com: On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote: Hi Szymon I found a small bug - it doesn't escape | well postgres=# select * from mytab ; a | numeric_b | c --+---+ Ahoj |10 | 2014-10-17 Hello|20 | 2014-10-18 Hi |30 | 2014-10-19 aaa| | | 2014-10-17 (4 rows) result [options=header,cols=literal,literal,literal,frame=all,grid=all] | ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++ | Ahoj | 10 | 2014-10-17 | Hello | 20 | 2014-10-18 | Hi | 30 | 2014-10-19 | aaa| | | 2014-10-17 | Next, I tested it with asciidoc and asciidoctor and I have a problem with asciidoctor - it doesn't respect aligning .. so numbers are aligned to left instead to right. When you use a option header then a formatting +++ is useless. Hi Pavel, thanks for the remarks. I've attached another version of the pach. It works a little better now, including escaping | and asciidoctor alignment support. it is fixed. Thank you. I fixed formatting - please, recheck it. I don't see any issue - it should be ready for commiter Regards Pavel Hi Pavel, thanks for the review and reformatting. It looks much better after the reformatting. thanks, Szymon
Re: [HACKERS] printing table in asciidoc with psql
2014-10-30 9:30 GMT+01:00 Szymon Guz mabew...@gmail.com: On 30 October 2014 09:04, Pavel Stehule pavel.steh...@gmail.com wrote: 2014-10-29 12:23 GMT+01:00 Szymon Guz mabew...@gmail.com: On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote: Hi Szymon I found a small bug - it doesn't escape | well postgres=# select * from mytab ; a | numeric_b | c --+---+ Ahoj |10 | 2014-10-17 Hello|20 | 2014-10-18 Hi |30 | 2014-10-19 aaa| | | 2014-10-17 (4 rows) result [options=header,cols=literal,literal,literal,frame=all,grid=all] | ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++ | Ahoj | 10 | 2014-10-17 | Hello | 20 | 2014-10-18 | Hi | 30 | 2014-10-19 | aaa| | | 2014-10-17 | Next, I tested it with asciidoc and asciidoctor and I have a problem with asciidoctor - it doesn't respect aligning .. so numbers are aligned to left instead to right. When you use a option header then a formatting +++ is useless. Hi Pavel, thanks for the remarks. I've attached another version of the pach. It works a little better now, including escaping | and asciidoctor alignment support. it is fixed. Thank you. I fixed formatting - please, recheck it. I don't see any issue - it should be ready for commiter Regards Pavel Hi Pavel, thanks for the review and reformatting. It looks much better after the reformatting. ok so 1. There are no any objections against proposed and implemented feature. This patch contains just implementation of asciidoc format and nothing else. It has zero impact on current code. 2. There are no problems with patching and compilation. All current regress tests passed. 3. Patch contains doc and small set of regress tests. 4. I tested output against asciidoc and asciidoctor, I didn't find any problems. This patch is ready for commiter Thank you for patch Regards Pavel thanks, Szymon
Re: [HACKERS] printing table in asciidoc with psql
On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote: Hi Szymon I found a small bug - it doesn't escape | well postgres=# select * from mytab ; a | numeric_b | c --+---+ Ahoj |10 | 2014-10-17 Hello|20 | 2014-10-18 Hi |30 | 2014-10-19 aaa| | | 2014-10-17 (4 rows) result [options=header,cols=literal,literal,literal,frame=all,grid=all] | ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++ | Ahoj | 10 | 2014-10-17 | Hello | 20 | 2014-10-18 | Hi | 30 | 2014-10-19 | aaa| | | 2014-10-17 | Next, I tested it with asciidoc and asciidoctor and I have a problem with asciidoctor - it doesn't respect aligning .. so numbers are aligned to left instead to right. When you use a option header then a formatting +++ is useless. Hi Pavel, thanks for the remarks. I've attached another version of the pach. It works a little better now, including escaping | and asciidoctor alignment support. thanks, Szymon diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index e7fcc73..cd64b88 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2092,8 +2092,8 @@ lo_import 152801 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), - literallatex-longtable/literal, or - literaltroff-ms/literal. + literallatex-longtable/literal, + literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para @@ -2120,7 +2120,8 @@ lo_import 152801 para The literalhtml/, literallatex/, - literallatex-longtable/literal, and literaltroff-ms/ + literallatex-longtable/literal, literaltroff-ms/, + and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 26089352..e00e47b 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -2248,6 +2248,9 @@ _align2string(enum printFormat in) case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } @@ -2321,9 +2324,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { - psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); + psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c index ae5fe88..b14b313 100644 --- a/src/bin/psql/help.c +++ b/src/bin/psql/help.c @@ -351,7 +351,7 @@ helpVariables(unsigned short int pager) fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); - fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); + fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style [ascii, old-ascii, unicode]\n)); fprintf(output, _( null set the string to be printed in place of a null value\n)); diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c index 3b3c3b7..83f268a 100644 --- a/src/bin/psql/print.c +++ b/src/bin/psql/print.c @@ -2475,6 +2475,217 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout) } } +/*/ +/* ASCIIDOC **/ +/*/ + +static void +asciidoc_escaped_print(const char *in, FILE *fout) +{ + const char *p; + for (p = in; *p; p++) + { +switch(*p) +{ + case '|': +fputs(\\|, fout); +break; + default: +fputc(*p, fout); +} + } +} + +static void +print_asciidoc_text(const printTableContent *cont, FILE *fout) +{ + bool opt_tuples_only = cont-opt-tuples_only; + unsigned short opt_border = cont-opt-border; + unsigned int i; + const char *const * ptr; + + if (cancel_pressed) + return; + + if (cont-opt-start_table) + { + /* print title */ +
Re: [HACKERS] printing table in asciidoc with psql
Hi Szymon I found a small bug - it doesn't escape | well postgres=# select * from mytab ; a | numeric_b | c --+---+ Ahoj |10 | 2014-10-17 Hello|20 | 2014-10-18 Hi |30 | 2014-10-19 aaa| | | 2014-10-17 (4 rows) result [options=header,cols=literal,literal,literal,frame=all,grid=all] | ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++ | Ahoj | 10 | 2014-10-17 | Hello | 20 | 2014-10-18 | Hi | 30 | 2014-10-19 | aaa| | | 2014-10-17 | Next, I tested it with asciidoc and asciidoctor and I have a problem with asciidoctor - it doesn't respect aligning .. so numbers are aligned to left instead to right. When you use a option header then a formatting +++ is useless. Regards Pavel 2014-09-17 21:26 GMT+02:00 Szymon Guz mabew...@gmail.com: On 17 September 2014 19:55, Szymon Guz mabew...@gmail.com wrote: On 17 September 2014 19:30, Peter Eisentraut pete...@gmx.net wrote: On 9/16/14 3:52 PM, Szymon Guz wrote: It's not finished yet, I'm not sure it there is any sense in supporting border types etc. AFAICT, Asciidoc doesn't support border types, so (if so) you should just ignore that setting. Too late, I've done something like this: border=0 [frame=none,grid=none] border=1 [frame=all,grid=none] border=2 [frame=all,grid=all] thanks, Szymon Hi, thanks for all the remarks. I've attached another version of this patch. I think it's done. - This works: `\pset format asciidoc` - Output is formatted as asciidoc tables. - There is support for borders {0,1,2}. The attached html file was made by running tests for psql, taking the asciidoc tables from it, converting to html with `asciidoc file`. -- border = 0 - [frame=none,grid=none] -- border = 1 - [frame=none,grid=all] -- border = 2 - [frame=all,grid=all] - There are also tests. -- For normal and extended mode combined with each of the border values. -- With column names made of characters which need escaping -- With values: (with escape needed characters, string '11' and integer 11 - they should have different right-left alignment). - Documentation for psql is updated. - According to Emanuel's advice: help.c is updated. The attached html file contains tables from the test in this order: normal, border 0 normal, border 1 normal, border 2 expanded, border 0 expanded, border 1 expanded, border 2 regards, Szymon -- 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] printing table in asciidoc with psql
El 16/09/14 16:52, Szymon Guz escribió: Hi, I've been working a little bit on a patch for printing tables in asciidoc with psql. It's not finished yet, I'm not sure it there is any sense in supporting border types etc. The code is not cleared so far, but any remarks on the style not playing well with the normal postgres style of code are welcomed. The code just works. With extended and normal modes. With table columns made of funny characters, with alignment of data in table cells. I was trying to implement it similar to the html export function, however escaping of the strings was much easier, as the normal html-way substitution is not easy to implement in asciidoc. I'd like to ask you for any advices for this code. thanks, Szymon Please add asciidoc in src/bin/psql/help.c[354] 354,96-103 fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); Tested the patch and worked fine. -- -- Emanuel Calvo http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] printing table in asciidoc with psql
2014-09-16 21:52 GMT+02:00 Szymon Guz mabew...@gmail.com: Hi, I've been working a little bit on a patch for printing tables in asciidoc with psql. It's not finished yet, I'm not sure it there is any sense in supporting border types etc. The code is not cleared so far, but any remarks on the style not playing well with the normal postgres style of code are welcomed. The code just works. With extended and normal modes. With table columns made of funny characters, with alignment of data in table cells. I was trying to implement it similar to the html export function, however escaping of the strings was much easier, as the normal html-way substitution is not easy to implement in asciidoc. I'd like to ask you for any advices for this code. nice +1 Pavel thanks, Szymon -- 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] printing table in asciidoc with psql
On 9/16/14 3:52 PM, Szymon Guz wrote: It's not finished yet, I'm not sure it there is any sense in supporting border types etc. AFAICT, Asciidoc doesn't support border types, so (if so) you should just ignore that setting. -- 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] printing table in asciidoc with psql
On 17 September 2014 19:30, Peter Eisentraut pete...@gmx.net wrote: On 9/16/14 3:52 PM, Szymon Guz wrote: It's not finished yet, I'm not sure it there is any sense in supporting border types etc. AFAICT, Asciidoc doesn't support border types, so (if so) you should just ignore that setting. Too late, I've done something like this: border=0 [frame=none,grid=none] border=1 [frame=all,grid=none] border=2 [frame=all,grid=all] thanks, Szymon
Re: [HACKERS] printing table in asciidoc with psql
On 17 September 2014 19:55, Szymon Guz mabew...@gmail.com wrote: On 17 September 2014 19:30, Peter Eisentraut pete...@gmx.net wrote: On 9/16/14 3:52 PM, Szymon Guz wrote: It's not finished yet, I'm not sure it there is any sense in supporting border types etc. AFAICT, Asciidoc doesn't support border types, so (if so) you should just ignore that setting. Too late, I've done something like this: border=0 [frame=none,grid=none] border=1 [frame=all,grid=none] border=2 [frame=all,grid=all] thanks, Szymon Hi, thanks for all the remarks. I've attached another version of this patch. I think it's done. - This works: `\pset format asciidoc` - Output is formatted as asciidoc tables. - There is support for borders {0,1,2}. The attached html file was made by running tests for psql, taking the asciidoc tables from it, converting to html with `asciidoc file`. -- border = 0 - [frame=none,grid=none] -- border = 1 - [frame=none,grid=all] -- border = 2 - [frame=all,grid=all] - There are also tests. -- For normal and extended mode combined with each of the border values. -- With column names made of characters which need escaping -- With values: (with escape needed characters, string '11' and integer 11 - they should have different right-left alignment). - Documentation for psql is updated. - According to Emanuel's advice: help.c is updated. The attached html file contains tables from the test in this order: normal, border 0 normal, border 1 normal, border 2 expanded, border 0 expanded, border 1 expanded, border 2 regards, Szymon text/html; charset=US-ASCII; name="asciidoc_output.html": Unrecognized diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index e7fcc73..cd64b88 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2092,8 +2092,8 @@ lo_import 152801 literalaligned/literal, literalwrapped/literal, literalhtml/literal, literallatex/literal (uses literaltabular/literal), - literallatex-longtable/literal, or - literaltroff-ms/literal. + literallatex-longtable/literal, + literaltroff-ms/literal, or literalasciidoc/literal. Unique abbreviations are allowed. (That would mean one letter is enough.) /para @@ -2120,7 +2120,8 @@ lo_import 152801 para The literalhtml/, literallatex/, - literallatex-longtable/literal, and literaltroff-ms/ + literallatex-longtable/literal, literaltroff-ms/, + and literalasciidoc/ formats put out tables that are intended to be included in documents using the respective mark-up language. They are not complete documents! This might not be diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 2227db4..ae6b106 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -2247,6 +2247,9 @@ _align2string(enum printFormat in) case PRINT_TROFF_MS: return troff-ms; break; + case PRINT_ASCIIDOC: + return asciidoc; + break; } return unknown; } @@ -2316,9 +2319,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) popt-topt.format = PRINT_LATEX_LONGTABLE; else if (pg_strncasecmp(troff-ms, value, vallen) == 0) popt-topt.format = PRINT_TROFF_MS; + else if (pg_strncasecmp(asciidoc, value, vallen) == 0) + popt-topt.format = PRINT_ASCIIDOC; else { - psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n); + psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n); return false; } diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c index 6035a77..66da6ec 100644 --- a/src/bin/psql/help.c +++ b/src/bin/psql/help.c @@ -351,7 +351,7 @@ helpVariables(unsigned short int pager) fprintf(output, _( expanded (or x)toggle expanded output\n)); fprintf(output, _( fieldsep field separator for unaligned output (default '|')\n)); fprintf(output, _( fieldsep_zero set field separator in unaligned mode to zero\n)); - fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); + fprintf(output, _( format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n)); fprintf(output, _( footer enable or disable display of the table footer [on, off]\n)); fprintf(output, _( linestyle set the border line drawing style [ascii, old-ascii, unicode]\n)); fprintf(output, _( null set the string to be printed in place of a null value\n)); diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c index 3b3c3b7..956bbb1 100644 --- a/src/bin/psql/print.c +++ b/src/bin/psql/print.c @@ -2475,6 +2475,200 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout) } } +/*/ +/* ASCIIDOC **/