Re: psql output locations

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: psql output locations
Дата
Msg-id 1323720261.20924.15.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на psql output locations  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: psql output locations  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: static or dynamic libpgport
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: static or dynamic libpgport