psql output locations
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the output in the query output channel controlled
by \o, and not just the output of the query itself. Because that would
make it possible to control it from inside the script. Now, this made
me notice:
* There are 102 calls to psql_error(), 42 direct uses of
fprintf(stderr), and 7 uses of fputs(stderr). And there is also
write_stderr() used in the cancel handler. Is there actually a point
behind all those direct uses, or should they really be psql_error()
calls?
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the output in the query output channel controlled
by \o, and not just the output of the query itself. Because that would
make it possible to control it from inside the script. Now, this made
me notice:* There are 102 calls to psql_error(), 42 direct uses of
fprintf(stderr), and 7 uses of fputs(stderr). And there is also
write_stderr() used in the cancel handler. Is there actually a point
behind all those direct uses, or should they really be psql_error()
calls?
Some of this could probably be more more uniform. But I don't see how
this related to your question. All the output goes uniformly to stderr,
which is what matters.
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?
Everything that is not an error goes to stdout, no? Except the query
output, if you change it.
Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.
On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut <peter_e@gmx.net> wrote:
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the output in the query output channel controlled
by \o, and not just the output of the query itself. Because that would
make it possible to control it from inside the script. Now, this made
me notice:* There are 102 calls to psql_error(), 42 direct uses of
fprintf(stderr), and 7 uses of fputs(stderr). And there is also
write_stderr() used in the cancel handler. Is there actually a point
behind all those direct uses, or should they really be psql_error()
calls?Some of this could probably be more more uniform. But I don't see how
this related to your question. All the output goes uniformly to stderr,
which is what matters.
I was overriding psql_error() to write it to the same file as the \o
output was written too - and that only worked for some of the errors.
It seemed like the logical place to put such a redirection...
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.
Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...
That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? �Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.
I have done as you suggested with the attached patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
psql.difftext/x-diff; charset=us-asciiDownload+75-74
Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012:
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.I have done as you suggested with the attached patch.
The very first hunk in your patch changes code that seems to be
explicitely checking the "interactive" flag. Is the change really
wanted there? Note Magnus explicitely commented about those in his
original post.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012:
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? �Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.I have done as you suggested with the attached patch.
The very first hunk in your patch changes code that seems to be
explicitely checking the "interactive" flag. Is the change really
wanted there? Note Magnus explicitely commented about those in his
original post.
I noticed that but the output would be the same because there is no
input file location to trigger. I thought the interactive flag was
there just to provide more customized text.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Fri, Aug 17, 2012 at 12:28:58PM -0400, Bruce Momjian wrote:
On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012:
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?Everything that is not an error goes to stdout, no? �Except the query
output, if you change it.Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.Yeah, that might be it. Or I need separate settings for "put errors in
the query output stream" and "put non-query-output-but-also-non-errors
in the query output stream". The effect would be the same, I guess...That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.I have done as you suggested with the attached patch.
The very first hunk in your patch changes code that seems to be
explicitely checking the "interactive" flag. Is the change really
wanted there? Note Magnus explicitely commented about those in his
original post.I noticed that but the output would be the same because there is no
input file location to trigger. I thought the interactive flag was
there just to provide more customized text.
Applied.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +