Re: 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.

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

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

2014-09-16 21:52 GMT+02:00 Szymon Guz <mabewlun(at)gmail(dot)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(at)postgresql(dot)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.

On 17 September 2014 19:30, Peter Eisentraut <peter_e(at)gmx(dot)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

On 17 September 2014 19:55, Szymon Guz <mabewlun(at)gmail(dot)com> wrote:

>
>
> On 17 September 2014 19:30, Peter Eisentraut <peter_e(at)gmx(dot)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

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|aaaa | 2222 | 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|aaaa | 2222 | 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 "+++xxxx++++" is useless.

Regards

Pavel

2014-09-17 21:26 GMT+02:00 Szymon Guz <mabewlun(at)gmail(dot)com>:

>
>
> On 17 September 2014 19:55, Szymon Guz <mabewlun(at)gmail(dot)com> wrote:
>
>>
>>
>> On 17 September 2014 19:30, Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

On 17 October 2014 09:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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|aaaa | 2222 | 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|aaaa | 2222 | 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 "+++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,
Szymon

2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun(at)gmail(dot)com>:

>
>
> On 17 October 2014 09:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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|aaaa | 2222 | 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|aaaa | 2222 | 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 "+++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
>

On 30 October 2014 09:04, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

>
>
> 2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun(at)gmail(dot)com>:
>
>>
>>
>> On 17 October 2014 09:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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|aaaa | 2222 | 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|aaaa | 2222 | 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 "+++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
>

Hi Pavel,
thanks for the review and reformatting. It looks much better after the
reformatting.

thanks,
Szymon

2014-10-30 9:30 GMT+01:00 Szymon Guz <mabewlun(at)gmail(dot)com>:

> On 30 October 2014 09:04, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>>
>>
>> 2014-10-29 12:23 GMT+01:00 Szymon Guz <mabewlun(at)gmail(dot)com>:
>>
>>>
>>>
>>> On 17 October 2014 09:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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|aaaa | 2222 | 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|aaaa | 2222 | 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 "+++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
>>
>
>
> 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
>

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(at)2ndquadrant(dot)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 tomorrow

Regards

Pavel

2014-11-14 21:00 GMT+01:00 Szymon Guz <mabewlun(at)gmail(dot)com>:

>
> On 14 November 2014 20:57, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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 Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

On Mon, Nov 17, 2014 at 7:48 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2014-11-07 22:37 GMT+01:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(dot)paquier(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, Mar 22, 2015 at 10:09 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Wed, Mar 25, 2015 at 4:52 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 31 March 2015 at 16:35, Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)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-top">stuff</th>
<th class="tableblock halign-center valign-top">|&amp;.^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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +