On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut <pete...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
