Re: psql output locations - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: psql output locations
Date
Msg-id 1323720261.20924.15.camel@vanquo.pezone.net
Whole thread Raw
In response to psql output locations  (Magnus Hagander <magnus@hagander.net>)
Responses Re: psql output locations
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: static or dynamic libpgport
Next
From: Andrew Dunstan
Date:
Subject: Re: static or dynamic libpgport