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 <mag...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
