Thread: 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. +
Attachment
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. +