Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-11-10 16:38 GMT+01:00 Fabien COELHO :

>
> Hello,
>
> Maybe I'm missing something, but it looks that it could be made to work
>>> without adding another boolean.
>>>
>>
>> The tuples only cannot be disabled, because then other parts print number
>> of rows
>>
>> postgres=# \pset format unaligned
>> Output format is unaligned.
>>
>> postgres=# select 10 as a, 20 as b;
>> a|b
>> 10|20
>> (1 row) <
>>
>
> Argh. Too bad.
>
> I'm not at ease with having two bools which nearly mean the opposite one
> of the other but not exactly... however I'm not sure that there is a
> simpler way out of this, some exception handling is needed one way or the
> other, either within the header or within the footer... Maybe the whole
> topt logic should be reviewed, but that is not the point of this patch.
>

I don't think so it is not correct - this mean tuples only + header.
Probably the best implementation is something three state - all, tuples
only, tuples only and header. But it mean much more changes in psql logic -
not adequate to size of this patch


> So I switched the patch to "ready for committer".
>

Thank you very much

Regards

Pavel


>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Hello,

Maybe I'm missing something, but it looks that it could be made to work 
without adding another boolean.


The tuples only cannot be disabled, because then other parts print number
of rows

postgres=# \pset format unaligned
Output format is unaligned.

postgres=# select 10 as a, 20 as b;
a|b
10|20
(1 row) <


Argh. Too bad.

I'm not at ease with having two bools which nearly mean the opposite one 
of the other but not exactly... however I'm not sure that there is a 
simpler way out of this, some exception handling is needed one way or the 
other, either within the header or within the footer... Maybe the whole 
topt logic should be reviewed, but that is not the point of this patch.


So I switched the patch to "ready for committer".

--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-11-10 8:12 GMT+01:00 Fabien COELHO :

>
> ISTM that you can remove "force_column_header" and just set "tuple_only"
>>> to what you need, that is you do not need to change anything in function
>>> "print_unaligned_text".
>>>
>>
>> Last point is not possible - I would not to break original tuple only
>> mode.
>>
>
> Hmmm... I do not understand. I can see only one use of force_column_header
> in the function:
>
>  -   if (!opt_tuples_only)
>  +   if (!opt_tuples_only || opt_force_column_header)
>
> So I would basically suggest to do:
>
>  my_popt.topt.tuples_only = !pset.g_raw_header;
>
> in the driver. Looking at the detailed code in that function, probably you
> need to set start_table to on when headers are needed and stop_table to off
> for the raw mode anyway?
>
> Maybe I'm missing something, but it looks that it could be made to work
> without adding another boolean.
>

The tuples only cannot be disabled, because then other parts print number
of rows

postgres=# \pset format unaligned
Output format is unaligned.

postgres=# select 10 as a, 20 as b;
a|b
10|20
(1 row) <



> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

ISTM that you can remove "force_column_header" and just set "tuple_only"
to what you need, that is you do not need to change anything in function
"print_unaligned_text".


Last point is not possible - I would not to break original tuple only mode.


Hmmm... I do not understand. I can see only one use of force_column_header 
in the function:


 -   if (!opt_tuples_only)
 +   if (!opt_tuples_only || opt_force_column_header)

So I would basically suggest to do:

 my_popt.topt.tuples_only = !pset.g_raw_header;

in the driver. Looking at the detailed code in that function, probably you 
need to set start_table to on when headers are needed and stop_table to 
off for the raw mode anyway?


Maybe I'm missing something, but it looks that it could be made to work 
without adding another boolean.


--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-11-09 21:12 GMT+01:00 Pavel Stehule :

>
>
> 2017-11-09 21:03 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> I hope so I fixed all mentioned issues.
>>>
>>
>> Patch applies with a warning:
>>
>>  > git apply ~/psql-graw-2.patch
>>  /home/fabien/psql-graw-2.patch:192: new blank line at EOF.
>>  +
>>  warning: 1 line adds whitespace errors.
>>
>> Otherwise it compiles. "make check" ok. doc gen ok.
>>
>> Two spurious empty lines are added before StoreQueryTuple.
>>
>> Doc: "If + is appended to the command name, a column
>> names are displayed."
>>
>> I suggest instead: "When + is appended, column names
>> are also displayed."
>>
>> ISTM that you can remove "force_column_header" and just set "tuple_only"
>> to what you need, that is you do not need to change anything in function
>> "print_unaligned_text".
>>
>
> Last point is not possible - I would not to break original tuple only
> mode.
>
>
updated patch




> Pavel
>
>>
>> --
>> Fabien.
>>
>
>
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index e520cdf3ba..457a59eeab 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2020,6 +2020,19 @@ CREATE INDEX
   
 
 
+  
+\graw[+] [ filename ]
+\graw[+]  [ |command ]
+
+
+\graw is equivalent to \g, but
+forces unaligned output mode for this query. When +
+is appended, column names are also displayed.
+
+
+  
+
+
   
 \gset [ prefix ]
 
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 8cc4de3878..b3461291eb 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -332,7 +332,8 @@ exec_command(const char *cmd,
 		status = exec_command_errverbose(scan_state, active_branch);
 	else if (strcmp(cmd, "f") == 0)
 		status = exec_command_f(scan_state, active_branch);
-	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
+	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0 ||
+			 strcmp(cmd, "graw") == 0 || strcmp(cmd, "graw+") == 0)
 		status = exec_command_g(scan_state, active_branch, cmd);
 	else if (strcmp(cmd, "gdesc") == 0)
 		status = exec_command_gdesc(scan_state, active_branch);
@@ -1232,6 +1233,7 @@ exec_command_f(PsqlScanState scan_state, bool active_branch)
 
 /*
  * \g [filename] -- send query, optionally with output to file/pipe
+ * \graw [filename] -- same as \g with raw format
  * \gx [filename] -- same as \g, with expanded mode forced
  */
 static backslashResult
@@ -1254,6 +1256,10 @@ exec_command_g(PsqlScanState scan_state, bool active_branch, const char *cmd)
 		free(fname);
 		if (strcmp(cmd, "gx") == 0)
 			pset.g_expanded = true;
+		else if (strcmp(cmd, "graw") == 0)
+			pset.g_raw = true;
+		else if (strcmp(cmd, "graw+") == 0)
+			pset.g_raw_header = true;
 		status = PSQL_CMD_SEND;
 	}
 	else
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 7a91a44b2b..9f7ef51dfb 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -865,6 +865,14 @@ PrintQueryTuples(const PGresult *results)
 	if (pset.g_expanded)
 		my_popt.topt.expanded = 1;
 
+	/* one-shot raw output requested by \raw and \graw+ */
+	else if (pset.g_raw || pset.g_raw_header)
+	{
+		my_popt.topt.format = PRINT_UNALIGNED;
+		my_popt.topt.tuples_only = true;
+		my_popt.topt.force_column_header = pset.g_raw_header;
+	}
+
 	/* write output to \g argument, if any */
 	if (pset.gfname)
 	{
@@ -1517,6 +1525,10 @@ sendquery_cleanup:
 	/* reset \gx's expanded-mode flag */
 	pset.g_expanded = false;
 
+	/* reset \graw flags */
+	pset.g_raw = false;
+	pset.g_raw_header = false;
+
 	/* reset \gset trigger */
 	if (pset.gset_prefix)
 	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index a926c40b9b..e573711434 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -167,7 +167,7 @@ slashUsage(unsigned short int pager)
 	 * Use "psql --help=commands | wc" to count correctly.  It's okay to count
 	 * the USE_READLINE line even in builds without that.
 	 */
-	output = PageOutput(125, pager ? &(pset.popt.topt) : NULL);
+	output = PageOutput(126, pager ? &(pset.popt.topt) : NULL);
 
 	fprintf(output, _("General\n"));
 	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
@@ -176,6 +176,7 @@ slashUsage(unsigned short int pager)
 	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
 	fprintf(output, _("  \\gdesc describe result of query, without executing it\n"));
 	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
+	fprintf(output, _("  \\graw[+] [FILE]as \\g, but forces unaligned raw output mode\n"));
 	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
 	fprintf(output, _("  \\gx [FILE] as \\g, but forces expanded output mode\n"));
 	fprintf(output, _("  \\q quit psql\

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-11-09 21:03 GMT+01:00 Fabien COELHO :

>
> Hello Pavel,
>
> I hope so I fixed all mentioned issues.
>>
>
> Patch applies with a warning:
>
>  > git apply ~/psql-graw-2.patch
>  /home/fabien/psql-graw-2.patch:192: new blank line at EOF.
>  +
>  warning: 1 line adds whitespace errors.
>
> Otherwise it compiles. "make check" ok. doc gen ok.
>
> Two spurious empty lines are added before StoreQueryTuple.
>
> Doc: "If + is appended to the command name, a column
> names are displayed."
>
> I suggest instead: "When + is appended, column names
> are also displayed."
>
> ISTM that you can remove "force_column_header" and just set "tuple_only"
> to what you need, that is you do not need to change anything in function
> "print_unaligned_text".
>

Last point is not possible - I would not to break original tuple only mode.

Pavel

>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Hello Pavel,


I hope so I fixed all mentioned issues.


Patch applies with a warning:

 > git apply ~/psql-graw-2.patch
 /home/fabien/psql-graw-2.patch:192: new blank line at EOF.
 +
 warning: 1 line adds whitespace errors.

Otherwise it compiles. "make check" ok. doc gen ok.

Two spurious empty lines are added before StoreQueryTuple.

Doc: "If + is appended to the command name, a column 
names are displayed."


I suggest instead: "When + is appended, column names 
are also displayed."


ISTM that you can remove "force_column_header" and just set "tuple_only" 
to what you need, that is you do not need to change anything in function 
"print_unaligned_text".


--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

Hi

2017-08-24 5:50 GMT+02:00 Fabien COELHO :

>
> Hello Pavel,
>
> I have added the patch to the next commitfest.
>
> Patch applies, compiles, works.
>
> I'm okay with the names graw/graw+, and for having such short-hands.
>
> Missing break in switch, even if last item and useless, because other
> items do it... Also should be added at its place in alphabetical order?
>
> "column_header" is somehow redundant with "tuples_only". Use the
> existing one instead of adding a new one?
>
> More generally, ISTM that the same effect could be achieved without
> adding a new print function, but by setting more options (separator,
> ...) and calling an existing print function. If so, I think it would
> reduce the code size.
>
> Missing help entry.
>
> Missing non regression tests.
>
> Missing documentation.
>
>
I hope so I fixed all mentioned issues.

Regards

Pavel


> --
> Fabien.
>
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index e520cdf3ba..9e7030f247 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2020,6 +2020,19 @@ CREATE INDEX
   
 
 
+  
+\graw[+] [ filename ]
+\graw[+]  [ |command ]
+
+
+\graw is equivalent to \g, but
+forces unaligned output mode for this query. If +
+is appended to the command name, a column names are displayed.
+
+
+  
+
+
   
 \gset [ prefix ]
 
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 8cc4de3878..b3461291eb 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -332,7 +332,8 @@ exec_command(const char *cmd,
 		status = exec_command_errverbose(scan_state, active_branch);
 	else if (strcmp(cmd, "f") == 0)
 		status = exec_command_f(scan_state, active_branch);
-	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
+	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0 ||
+			 strcmp(cmd, "graw") == 0 || strcmp(cmd, "graw+") == 0)
 		status = exec_command_g(scan_state, active_branch, cmd);
 	else if (strcmp(cmd, "gdesc") == 0)
 		status = exec_command_gdesc(scan_state, active_branch);
@@ -1232,6 +1233,7 @@ exec_command_f(PsqlScanState scan_state, bool active_branch)
 
 /*
  * \g [filename] -- send query, optionally with output to file/pipe
+ * \graw [filename] -- same as \g with raw format
  * \gx [filename] -- same as \g, with expanded mode forced
  */
 static backslashResult
@@ -1254,6 +1256,10 @@ exec_command_g(PsqlScanState scan_state, bool active_branch, const char *cmd)
 		free(fname);
 		if (strcmp(cmd, "gx") == 0)
 			pset.g_expanded = true;
+		else if (strcmp(cmd, "graw") == 0)
+			pset.g_raw = true;
+		else if (strcmp(cmd, "graw+") == 0)
+			pset.g_raw_header = true;
 		status = PSQL_CMD_SEND;
 	}
 	else
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 7a91a44b2b..aeec302eae 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -865,6 +865,14 @@ PrintQueryTuples(const PGresult *results)
 	if (pset.g_expanded)
 		my_popt.topt.expanded = 1;
 
+	/* one-shot raw output requested by \raw and \graw+ */
+	else if (pset.g_raw || pset.g_raw_header)
+	{
+		my_popt.topt.format = PRINT_UNALIGNED;
+		my_popt.topt.tuples_only = true;
+		my_popt.topt.force_column_header = pset.g_raw_header;
+	}
+
 	/* write output to \g argument, if any */
 	if (pset.gfname)
 	{
@@ -893,6 +901,8 @@ PrintQueryTuples(const PGresult *results)
 }
 
 
+
+
 /*
  * StoreQueryTuple: assuming query result is OK, save data into variables
  *
@@ -1517,6 +1527,10 @@ sendquery_cleanup:
 	/* reset \gx's expanded-mode flag */
 	pset.g_expanded = false;
 
+	/* reset \graw flags */
+	pset.g_raw = false;
+	pset.g_raw_header = false;
+
 	/* reset \gset trigger */
 	if (pset.gset_prefix)
 	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index a926c40b9b..e573711434 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -167,7 +167,7 @@ slashUsage(unsigned short int pager)
 	 * Use "psql --help=commands | wc" to count correctly.  It's okay to count
 	 * the USE_READLINE line even in builds without that.
 	 */
-	output = PageOutput(125, pager ? &(pset.popt.topt) : NULL);
+	output = PageOutput(126, pager ? &(pset.popt.topt) : NULL);
 
 	fprintf(output, _("General\n"));
 	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
@@ -176,6 +176,7 @@ slashUsage(unsigned short int pager)
 	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
 	fprintf(output, _("  \\gdesc describe result of query, without executing it\n"));
 	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
+	fprintf(output, _("  \\graw[+] [FILE]as \\g, but forces unaligned raw output mode\n"));
 	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
 	fprintf(output, _("  \\gx [FILE] as \\g, but f

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Argh, sorry, I put it in the September commitfest, and it seems that it
cannot be changed afterwards.

Maybe you can close it and redeclare it in the commitfest you want?


It can be moved


Indeed it can. Feel free to move it, then.

--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-08-24 17:27 GMT+02:00 Fabien COELHO :

>
> Hello,
>
> I'll wait to winter commitfest
>>
>
> Argh, sorry, I put it in the September commitfest, and it seems that it
> cannot be changed afterwards.
>
> Maybe you can close it and redeclare it in the commitfest you want?
>

It can be moved


>
> for some other ideas, tests, comments - it is topic for PostgreSQL 11, and
>> then there are a time for discussion.
>>
>
> I was rather seeing that as a small patch which could have been processed
> quickly, but if you expect feedback maybe it is better to give it more time.


I would to verify format, but thank you very much for your interest :)

Regards

Pavel




>
>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Hello,


I'll wait to winter commitfest


Argh, sorry, I put it in the September commitfest, and it seems that it 
cannot be changed afterwards.


Maybe you can close it and redeclare it in the commitfest you want?

for some other ideas, tests, comments - it is topic for PostgreSQL 11, 
and then there are a time for discussion.


I was rather seeing that as a small patch which could have been processed 
quickly, but if you expect feedback maybe it is better to give it more 
time.


--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-08-24 8:53 GMT+02:00 Fabien COELHO :

>
> "column_header" is somehow redundant with "tuples_only". Use the
>>> existing one instead of adding a new one?
>>>
>>
>> It is different - a result of tuples_only is just tuples - not column
>> names, not title, footer. I needed new special flag for enhancing
>> tuples_only to print column names
>>
>
> I do not understand. If you keep the special print_raw function, it can
> use tuples_only as true for without column names, and false for with column
> names?


yes - in this case you have true.


>
>
> More generally, ISTM that the same effect could be achieved without
>>> adding a new print function, but by setting more options (separator,
>>> ...) and calling an existing print function. If so, I think it would
>>> reduce the code size.
>>>
>>
>> Maybe, maybe not. removing PRINT_RAW you need to enhance PRINT_UNALIGNED
>> to
>> use one shot parameters and you have to teach it to print column names in
>> tuples_only mode. The code's length will be same. The form of this patch
>> is
>> not final.
>>
>
> Hmmm. Ok. It depends on the change implication on the print unaligned
> function.


It is open - I'll wait to winter commitfest for some other ideas, tests,
comments - it is topic for PostgreSQL 11, and then there are a time for
discussion

Now, I'll be happy if some other people will test it with larger set of
applications and send me a feedback.

Regards

Pavel


>
>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

"column_header" is somehow redundant with "tuples_only". Use the
existing one instead of adding a new one?


It is different - a result of tuples_only is just tuples - not column
names, not title, footer. I needed new special flag for enhancing
tuples_only to print column names


I do not understand. If you keep the special print_raw function, it can 
use tuples_only as true for without column names, and false for with 
column names?



More generally, ISTM that the same effect could be achieved without
adding a new print function, but by setting more options (separator,
...) and calling an existing print function. If so, I think it would
reduce the code size.


Maybe, maybe not. removing PRINT_RAW you need to enhance PRINT_UNALIGNED to
use one shot parameters and you have to teach it to print column names in
tuples_only mode. The code's length will be same. The form of this patch is
not final.


Hmmm. Ok. It depends on the change implication on the print unaligned 
function.


--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

Hi

2017-08-24 5:50 GMT+02:00 Fabien COELHO :

>
> Hello Pavel,
>
> I have added the patch to the next commitfest.
>
> Patch applies, compiles, works.
>
> I'm okay with the names graw/graw+, and for having such short-hands.
>
> Missing break in switch, even if last item and useless, because other
> items do it... Also should be added at its place in alphabetical order?
>

I can do


>
> "column_header" is somehow redundant with "tuples_only". Use the
> existing one instead of adding a new one?
>

It is different - a result of tuples_only is just tuples - not column
names, not title, footer. I needed new special flag for enhancing
tuples_only to print column names


>
> More generally, ISTM that the same effect could be achieved without
> adding a new print function, but by setting more options (separator,
> ...) and calling an existing print function. If so, I think it would
> reduce the code size.
>

Maybe, maybe not. removing PRINT_RAW you need to enhance PRINT_UNALIGNED to
use one shot parameters and you have to teach it to print column names in
tuples_only mode. The code's length will be same. The form of this patch is
not final.


>
> Missing help entry.
>
> Missing non regression tests.
>
> Missing documentation.


yes - I wrote it like proof concept - be possible (for me, for others) to
verify usability of this commands (and design). I tested it against gnuplot
and looks it is works

Regards

Pavel


>
>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Hello Pavel,

I have added the patch to the next commitfest.

Patch applies, compiles, works.

I'm okay with the names graw/graw+, and for having such short-hands.

Missing break in switch, even if last item and useless, because other
items do it... Also should be added at its place in alphabetical order?

"column_header" is somehow redundant with "tuples_only". Use the
existing one instead of adding a new one?

More generally, ISTM that the same effect could be achieved without
adding a new print function, but by setting more options (separator,
...) and calling an existing print function. If so, I think it would
reduce the code size.

Missing help entry.

Missing non regression tests.

Missing documentation.

--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

Hi

2017-08-22 11:22 GMT+02:00 Pavel Stehule :

>
>
> 2017-08-22 10:46 GMT+02:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> One my idea is introduction new simple output format and execution command
>>> with result in this format.
>>>
>>> It should work something like
>>>
>>> \setenv GNUPLOT_OPTION '..'
>>> SELECT * FROM data
>>> \graw | gnuplot ...
>>>
>>
>> I understand that it is kind of a shortcut for:
>>
>>   \pset fieldsep ' '
>>   \pset format unaligned
>>   \pset tuples_only on
>>   -- possibly other settings...
>>   SELECT * FROM data \g | gnuplot '...'
>
>
>> And then you have to persuade gnuplot to take its data from stdin?
>
>
> There are some methods
>
> https://stackoverflow.com/questions/17543386/pipe-plot-
> data-to-gnuplot-script/17576571#17576571
>
>
>
postgres=# select pocet_muzu + pocet_zen from obce
postgres-# \graw | gnuplot -p -e "set terminal dumb; plot '-' with boxes"





  1.4e+06
+-+-+---+---++---+---+---+-+-+
  +   +   +   ++   +   +   +
+
  |   *'-' ***
|
  1.2e+06 +-+ *
 +-+
  |   *
 |
1e+06 +-+ *
 +-+
  |   *
 |
  |   *
 |
   80 +-+ *
 +-+
  |   *
 |
  |   *
 |
   60 +-+ *
 +-+
  |   *
 |
  |   *
 |
   40 +-+ * *
 +-+
  |   * **
|
   20 +-+ * **
+-+
  |   *   * **
|
  +   * *  *  +** *  **    *   *  * *  + ***  
+
0
+-+----+-+
-1000 0  10002000 3000400050006000
 7000


postgres=#




>
>>
>> --
>> Fabien.
>>
>
>
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 96f3a402a4..90f88a8280 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -335,7 +335,8 @@ exec_command(const char *cmd,
 		status = exec_command_errverbose(scan_state, active_branch);
 	else if (strcmp(cmd, "f") == 0)
 		status = exec_command_f(scan_state, active_branch);
-	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
+	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0 ||
+			 strcmp(cmd, "graw") == 0 || strcmp(cmd, "graw+") == 0)
 		status = exec_command_g(scan_state, active_branch, cmd);
 	else if (strcmp(cmd, "gexec") == 0)
 		status = exec_command_gexec(scan_state, active_branch);
@@ -1300,6 +1301,7 @@ exec_command_f(PsqlScanState scan_state, bool active_branch)
 
 /*
  * \g [filename] -- send query, optionally with output to file/pipe
+ * \graw [filename] -- same as \g with raw format
  * \gx [filename] -- same as \g, with expanded mode forced
  */
 static backslashResult
@@ -1322,6 +1324,10 @@ exec_command_g(PsqlScanState scan_state, bool active_branch, const char *cmd)
 		free(fname);
 		if (strcmp(cmd, "gx") == 0)
 			pset.g_expanded = true;
+		else if (strcmp(cmd, "graw") == 0)
+			pset.g_raw = true;
+		else if (strcmp(cmd, "graw+") == 0)
+			pset.g_raw_header = true;
 		status = PSQL_CMD_SEND;
 	}
 	else
@@ -3701,6 +3707,8 @@ _align2string(enum printFormat in)
 		case PRINT_TROFF_MS:
 			return "troff-ms";
 			break;
+		case PRINT_RAW:
+			return "raw";
 	}
 	return "unknown";
 }
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 044cdb82a7..05af28ee40 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -816,6 +816,12 @@ PrintQueryTuples(const PGresult *results)
 	/* one-shot expanded output requested via \gx */
 	if (pset.g_expanded)
 		my_popt.topt.expanded = 1;
+	else if (pset.g_raw || pset.g_raw_header)
+	{
+		my_popt.topt.format = PRINT_RAW;
+		my_popt.topt.tuples_only = true;
+		my_popt.topt.column_header = pset.g_raw_header;
+	}
 
 	/* write output to \g argument, if any */
 	if (pset.gfname)
@@ -845,6 +851,8 @@ PrintQueryTuples(const PGresult *results)
 }
 
 
+
+
 /*
  * StoreQueryTuple: assuming query result is OK, save data into variables
  *
@@ -1460,6 +1468,10 @@ sendquery_cleanup:
 	/* reset \gx's expanded-mode flag */
 	pset.g_expanded = false;
 
+	/* reset \graw flags */
+	pset.g_raw = false;
+	pset.g_raw_header = false;
+
 	/* reset \gset trigger */
 	if (pset.gset_prefix)
 	{
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
index b78f151acd..6a2fb6b2dd 100644
--- a/src/bin/psql/settings.h
+++ b/src/bin/psql/settings.h
@@ -92,6 +92,8 @@ typedef struct _psqlSettings
 
 	char	   *gfname;			/* one-shot file output argument for \g */
 	bool		g_expanded;		/* one-shot expanded output requested via \gx */
+	bool		g_raw;			/* one-shot raw format for \graw */
+	bool		g_raw_header;	/* one-shot show header for \graw+ */
 	char	   *gset_prefix;	/* one-shot prefix argument for \gset */
 	bool		gexec_flag;		/* one-shot flag to exe

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-08-22 10:36 GMT+02:00 Aleksander Alekseev :

> Hi Pavel,
>
> > I am thinking about printing graphs in psql (mainly some histograms). I
> > found so gnuplot is able do very good graphs in console. The one issue is
> > user friendly (with less steps) generating data in good format for this
> > application.
> >
> > One my idea is introduction new simple output format and execution
> command
> > with result in this format.
> >
> > It should work something like
> >
> > \setenv GNUPLOT_OPTION '..'
> >
> > SELECT * FROM data
> >
> > \graw | gnuplot ...
> >
> > It can be used for any other applications R, ggplot, ..
> >
> > Ideas, comments?
>
> Sounds cool. On the other hand, I think it's kind of too domain specific
> task. So I wonder whether it could be generalized somehow so anyone
> could write an extension that would export data in any format in a
> friendly way.
>
> For instance:
>
> create extension export_to_gnuplot;
> select * from data
> \export_to_gnuplot | gnuplot ...
>

you are mixing server side and client side code. Maybe some time we can
write psql custom commands.

can be nice to have more pipes in series

so you can do

select * from data
\graw | histogram | gnuplot ...





>
> --
> Best regards,
> Aleksander Alekseev
>

Re: [HACKERS] proposal: psql command \graw

[Pavel Stehule]

2017-08-22 10:46 GMT+02:00 Fabien COELHO :

>
> Hello Pavel,
>
> One my idea is introduction new simple output format and execution command
>> with result in this format.
>>
>> It should work something like
>>
>> \setenv GNUPLOT_OPTION '..'
>> SELECT * FROM data
>> \graw | gnuplot ...
>>
>
> I understand that it is kind of a shortcut for:
>
>   \pset fieldsep ' '
>   \pset format unaligned
>   \pset tuples_only on
>   -- possibly other settings...
>   SELECT * FROM data \g | gnuplot '...'


> And then you have to persuade gnuplot to take its data from stdin?


There are some methods

https://stackoverflow.com/questions/17543386/pipe-plot-data-to-gnuplot-script/17576571#17576571



>
> --
> Fabien.
>

Re: [HACKERS] proposal: psql command \graw

[Fabien COELHO]

Hello Pavel,


One my idea is introduction new simple output format and execution command
with result in this format.

It should work something like

\setenv GNUPLOT_OPTION '..'
SELECT * FROM data
\graw | gnuplot ...


I understand that it is kind of a shortcut for:

  \pset fieldsep ' '
  \pset format unaligned
  \pset tuples_only on
  -- possibly other settings...
  SELECT * FROM data \g | gnuplot '...'

And then you have to persuade gnuplot to take its data from stdin?

--
Fabien.


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

Re: [HACKERS] proposal: psql command \graw

[Aleksander Alekseev]

Hi Pavel,

> I am thinking about printing graphs in psql (mainly some histograms). I
> found so gnuplot is able do very good graphs in console. The one issue is
> user friendly (with less steps) generating data in good format for this
> application.
> 
> One my idea is introduction new simple output format and execution command
> with result in this format.
> 
> It should work something like
> 
> \setenv GNUPLOT_OPTION '..'
> 
> SELECT * FROM data
> 
> \graw | gnuplot ...
> 
> It can be used for any other applications R, ggplot, ..
> 
> Ideas, comments?

Sounds cool. On the other hand, I think it's kind of too domain specific
task. So I wonder whether it could be generalized somehow so anyone
could write an extension that would export data in any format in a
friendly way.

For instance:

create extension export_to_gnuplot;
select * from data
\export_to_gnuplot | gnuplot ...

-- 
Best regards,
Aleksander Alekseev


signature.asc
Description: PGP signature

[HACKERS] proposal: psql command \graw

[Pavel Stehule]

Hi

I am thinking about printing graphs in psql (mainly some histograms). I
found so gnuplot is able do very good graphs in console. The one issue is
user friendly (with less steps) generating data in good format for this
application.

One my idea is introduction new simple output format and execution command
with result in this format.

It should work something like

\setenv GNUPLOT_OPTION '..'

SELECT * FROM data

\graw | gnuplot ...

It can be used for any other applications R, ggplot, ..

Ideas, comments?

Regards

Pavel