Re: [HACKERS] psql: stdout or stderr? - Mailing list pgsql-hackers

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> Is that really what you want?  I would have thought errors would be sent
> >> to stderr and that every thing else would go to stdout.
> 
> > Yes, this is new.  As I remember, some stuff is sent to stdout, and some
> > to stderr, and there was some reason for that, though I can't remember
> > what it was.  
> 
> I've always thought that psql is pretty inconsistent, arbitrary, and
> unreasonable about what it chooses to write to stdout vs stderr.
> 
> However, if we rejigger what goes where, we will surely break a lot of
> users' shell scripts, since those already expect particular output to go
> to one or the other.  (We'd also break all the regression tests, but
> at least those are within our power to fix.)
> 
> On the whole I'd vote against changing it --- a small improvement in
> consistency is not worth the pain it will cause.

OK, I will tell you what it does, and you tell me what it should do. 

Somewhere around 6.3, someone complained that he couldn't see how a
database reload was going, so he suggested that we output the table
information to stdout, and the SQL queries to stderr, so:
echo "select * from test;" | psql demodb

sends the text 'QUERY:  select * from test;' to stderr, and the table
contents of the select to stdout.  Now, if you do 'psql -q demodb', you
will not get anything on stderr, except error messages.  -q suppresses
the query output.

I believe this behavior also sends COPY FROM data rows to stdout, so a
pg_dump reload would probably want to see the SQL queries, so you can
see how far it had gotten, but not the data rows being loaded, which go
to stdout.

What we really need is three output streams from psql, one for data, one
for SQL queries, and one for errors.

Currently, the way we control this is to control how the SQL queries are
displayed.  Using -q causes them to be suppressed.  Using -e causes them
to be displayed twice.

What is the best way to handle this?  A bigger question is, "Can you
make sense of an error message if you don't have the SQL query that
caused it?"

Now I can say that the error return code from psql should accurately
show if an error occurred.  I did that code perhaps a year ago, and it
should still work.

Ideally, you would want errors in a separate file, but also be able to
go back and see the query with the error message right next to it.

So, basically I am saying that the default behavior is to output the SQL
queries to stderr, but -q turns that off.

I am interested in ways to improve this.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026