Thread: printing table in asciidoc with psql
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.
I'd like to ask you for any advices for this code.
Szymon
Attachment
El 16/09/14 16:52, Szymon Guz escribió:
thanks,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.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.
I'd like to ask you for any advices for this code.
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
2014-09-16 21:52 GMT+02:00 Szymon Guz <mabewlun@gmail.com>:
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.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.
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
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.
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On 17 September 2014 19:30, Peter Eisentraut<span dir="ltr"><<a href="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>></span> wrote:<br /><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><spanclass="">On 9/16/14 3:52 PM, Szymon Guz wrote:<br /> > It's not finished yet,I'm not sure it there is any sense in supporting<br /> > border types etc.<br /><br /></span>AFAICT, Asciidoc doesn'tsupport border types, so (if so) you should<br /> just ignore that setting.<br /></blockquote></div><br /></div><divclass="gmail_extra">Too late, I've done something like this:<br /><br /></div><div class="gmail_extra">border=0<br/>[frame="none",grid="none"]<br /><br /></div><div class="gmail_extra">border=1<br />[frame="all",grid="none"]<br/><br />border=2<br />[frame="all",grid="all"]<br /><br /></div><div class="gmail_extra">thanks,<br/>Szymon</div></div>
On 17 September 2014 19:55, Szymon Guz <mabewlun@gmail.com> wrote:
On 17 September 2014 19:30, Peter Eisentraut <peter_e@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
Attachment
Hi Szymon
I found a small bug - it doesn't escape "|" wellpostgres=# select * from mytab ;
a | numeric_b | c
----------+-----------+------------
Ahoj | 10 | 2014-10-17
Hello | 20 | 2014-10-18
Hi | 30 | 2014-10-19
aaa|aaaa | 2222 | 2014-10-17
(4 rows)
[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|aaaa | 2222 | 2014-10-17
|====
When you use a option "header" then a formatting "+++xxxx++++" is useless.
2014-09-17 21:26 GMT+02:00 Szymon Guz <mabewlun@gmail.com>:
Hi,On 17 September 2014 19:55, Szymon Guz <mabewlun@gmail.com> wrote:On 17 September 2014 19:30, Peter Eisentraut <peter_e@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,
Szymonthanks 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 2regards,Szymon
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@gmail.com> wrote:
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.resultHi SzymonI 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|aaaa | 2222 | 2014-10-17
(4 rows)
[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|aaaa | 2222 | 2014-10-17
|====When you use a option "header" then a formatting "+++xxxx++++" 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,
thanks,
Szymon
Attachment
2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:
On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@gmail.com> wrote: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.resultHi SzymonI 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|aaaa | 2222 | 2014-10-17
(4 rows)
[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|aaaa | 2222 | 2014-10-17
|====When you use a option "header" then a formatting "+++xxxx++++" 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
Attachment
On 30 October 2014 09:04, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@gmail.com> wrote: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.resultHi SzymonI 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|aaaa | 2222 | 2014-10-17
(4 rows)
[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|aaaa | 2222 | 2014-10-17
|====When you use a option "header" then a formatting "+++xxxx++++" 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 commiterRegardsPavel
Hi Pavel,
thanks for the review and reformatting. It looks much better after the reformatting.
thanks,
Szymon
Szymon
2014-10-30 9:30 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:
On 30 October 2014 09:04, Pavel Stehule <pavel.stehule@gmail.com> wrote:2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@gmail.com> wrote: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.resultHi SzymonI 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|aaaa | 2222 | 2014-10-17
(4 rows)
[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|aaaa | 2222 | 2014-10-17
|====When you use a option "header" then a formatting "+++xxxx++++" 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
RegardsPavelHi 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
Pavel
thanks,
Szymon
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 Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Is anyone going to submit a new version of this patch? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 14 November 2014 20:57, Alvaro Herrera <alvherre@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
Hi
I can fix reported bugs today or tomorrowPavel
2014-11-14 21:00 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:
On 14 November 2014 20:57, Alvaro Herrera <alvherre@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
Hi
2014-11-07 22:37 GMT+01:00 Alvaro Herrera <alvherre@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
Pavel
--
Álvaro Herrera http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Attachment
On Mon, Nov 17, 2014 at 7:48 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 2014-11-07 22:37 GMT+01:00 Alvaro Herrera <alvherre@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
On Wed, Dec 3, 2014 at 3:52 PM, Michael Paquier <michael.paquier@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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
On Sun, Mar 22, 2015 at 10:09 AM, Bruce Momjian <bruce@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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
On Wed, Mar 25, 2015 at 4:52 AM, Bruce Momjian <bruce@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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian <bruce@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
On Wed, Mar 25, 2015 at 09:37:08PM +0900, Michael Paquier wrote: > On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
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 <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
On 31 March 2015 at 16:35, Bruce Momjian <bruce@momjian.us> wrote:
I think I done gone broke it:
CREATE TABLE "| 3^.||moo|hello," (stuff int, "|&.^hje||" text);
INSERT INTO "| 3^.||moo|hello," VALUES (2,'hello');
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 <bruce@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)
....
[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-top">stuff</th>
<th class="tableblock halign-center valign-top">|&.^hje||2</th>
</tr>
</thead>
</table>
<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-top">stuff</th>
<th class="tableblock halign-center valign-top">|&.^hje||2</th>
</tr>
</thead>
</table>
Using asciidoctor 1.5.2.
--
Thom
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +