Re: [HACKERS] printing table in asciidoc with psql

2015-04-01 Thread Bruce Momjian
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

2015-03-31 Thread Bruce Momjian
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

2015-03-31 Thread Thom Brown
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

2015-03-31 Thread Bruce Momjian
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

2015-03-25 Thread Bruce Momjian
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

2015-03-25 Thread Michael Paquier
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

2015-03-25 Thread Bruce Momjian
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

2015-03-24 Thread Michael Paquier
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

2015-03-24 Thread Bruce Momjian
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

2015-03-23 Thread Bruce Momjian
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

2015-03-23 Thread Michael Paquier
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

2015-03-22 Thread Michael Paquier
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

2015-03-21 Thread Michael Paquier
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

2015-03-21 Thread Bruce Momjian
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

2015-03-20 Thread Bruce Momjian
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

2014-12-02 Thread Michael Paquier
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

2014-12-02 Thread Michael Paquier
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

2014-11-16 Thread Pavel Stehule
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

2014-11-15 Thread Pavel Stehule
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

2014-11-14 Thread Szymon Guz
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

2014-11-07 Thread Alvaro Herrera

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-30 Thread Pavel Stehule
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

2014-10-30 Thread Szymon Guz
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 Thread Pavel Stehule
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

2014-10-29 Thread Szymon Guz
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

2014-10-17 Thread Pavel Stehule
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

2014-09-17 Thread Emanuel Calvo

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-17 Thread Pavel Stehule
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

2014-09-17 Thread Peter Eisentraut
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

2014-09-17 Thread Szymon Guz
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

2014-09-17 Thread Szymon Guz
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 **/