printing table in asciidoc with psql

El 16/09/14 16:52, Szymon Guz escribi�:

Hi,
I've been working a little bit on a patch for printing tables in
asciidoc with psql.

It's not finished yet, I'm not sure it there is any sense in
supporting border types etc. The code is not cleared so far, but any
remarks on the style not playing well with the normal postgres style
of code are welcomed.

The code just works. With extended and normal modes. With table
columns made of funny characters, with alignment of data in table
cells. I was trying to implement it similar to the html export
function, however escaping of the strings was much easier, as the
normal html-way substitution is not easy to implement in asciidoc.

I'd like to ask you for any advices for this code.

thanks,
Szymon

Please add "asciidoc" in src/bin/psql/help.c[354]

354,96-103
fprintf(output, _(" format set output format
[unaligned, aligned, wrapped, html, latex, ..]\n"));

Tested the patch and worked fine.

--
--
Emanuel Calvo http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2014-09-16 21:52 GMT+02:00 Szymon Guz <mabewlun@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

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

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

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

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@gmail.com>:

On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@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|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@gmail.com>:

On 17 October 2014 09:01, Pavel Stehule <pavel.stehule@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|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

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:

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@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:

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Is anyone going to submit a new version of this patch?

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 tomorrow

Regards

Pavel

2014-11-14 21:00 GMT+01:00 Szymon Guz <mabewlun@gmail.com>:

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

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