Re: Submission Review: User control over psql error stream

Hi Karl,

Sorry for the slow reply ...

Excerpt from Karl O. Pinc <kop(at)meme(dot)com> On Mon, Dec 10, 2012 at 5:00 AM:

> I was thinking along the same lines, that case 2) stderr to a file
> or pipe needs addressing. I think it's necessary to address the
> issue now. Otherwise we risk cluttering up the syntax in
> inhospitable ways.

The discussion needs to be a little broader than stdout and stderr,
there are currently three output streams from psql:
- stdout - prompts, not tabular output such as the results from \set and \c
- stderr - errors, notices, ...
- query output - result from queries and \ commands which return
tables such as \l - this is what is currently piped or redirected by
\o

I see a patch like this adding a fourth - diagnostic output. While
this would probably be the same as stderr initially but I think that
the option to make them subtly different should be kept open.

> It occurs to me that my reply does not address the issue
> of case 3, displaying or not) errors to the terminal in
> addition to wherever else errors are sent.

I don't know of any precedent syntax for this - in *nix shells you'd
pipe to tee rather than modify the redirect in some way.

> I think you're right, whether or not errors continue to be sent
> to stdout when they are directed elsewhere should be a separate
> flag. My inclination is to have another special psql variable
> to control this but that would break backwards compatibility.
> Instead, let's work out a syntax for the rest of the functionality
> and try to fit this in.
>
> One nice thing about special psql variables is that they self-report
> their state. I mention this since we're adding more state.
> It would be nice if the chosen syntax does not preclude some
> additional tweaking to report on the state involving the
> output streams. (Although I don't think that needs to be
> a part of this patch.)

State reporting and reset tend to use the same syntax - the command
without parameters. I think the best route to achieve this would be
for the commands to set a variables which would be reported by \set.

In my initial list of what needed to be specified for output
management I missed one - whether file output should be appended or
should rewrite the file. It's not likely to be particularly useful for
query output but would matter for diagnostics.

Given all of these considerations I would propose changing your
calling syntax to:

\o reset all output redirection

\oq reset query output redirection
\o[q] [>] file query output to file
\o[q] >> file append query output to file
\o[q] | prog pipe query output to program
\o[q] {[>]|>>||}+ display query output on stdout in addition to redirection

\od reset query output redirection
\odq diagnostic output to query output stream
\odq + diagnostic output to stderr and query output
stream (same as \odq and \o + in combination)
\od [>] file diagnostic output to file
\od >> file append diagnostic output to file
\od | prog pipe diagnostic output to program
\od {[>]|>>||}+ display diagnostic output on stderr in addition to
redirection

To meet its original goals your patch would need to implement \o, \od,
\odq and \odq +.

Regards,
Alastair.