From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql output locations |
Date: | 2011-12-12 20:04:21 |
Message-ID: | 1323720261.20924.15.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-12-12 20:13:58 | Re: static or dynamic libpgport |
Previous Message | Tom Lane | 2011-12-12 19:59:41 | Re: static or dynamic libpgport |