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/
