Re: Submission Review: User control over psql error stream - Mailing list pgsql-hackers

Hi Alastair,

On 12/09/2012 02:13:32 PM, Alastair Turner wrote:
> Hi Karl,
>
> I have given the patch a quick review and read the related mails
> following its initial submission.

Thank you very much.

> - It's closed ended - there are three things about error output which
> affect where it's written to: does it go to query output, does it go
> somewhere else (a file or pipe), does it get displayed as well as
> going to the other destination. The patch addresses the first and
> third questions without making allowance for asking or dealing with
> second one. Internally I think this should be two bools rather than a
> custom tri-state, mainly because this would allow the addition of the
> error file option (in another patch, when the time came) with minimum
> intrusion.

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.

> - \pset is not the right place for this switch - all the
> documentation
> (including \?) indicate that psets are for controlling the display of
> result tables and this doesn't fit with the other options to \pset.
> Since this affects what goes into the output file I would think that
> this should be an option to \o. Maybe \o& ?

Before talking about syntax let's get semantics out of the way.

I think we're agreed that we want to be able to mix stderr
in with stdout.  It makes sense to me to be able to say,
as in shell, send stderr to wherever stdout is going,
without having to re-specify where stdout has actually gone.
This is especially needed in the case of pipes.

The big question is whether, after redirecting stderr
to stdout, redirecting stdout to someplace else also
then changes where stderr goes.  My inclination is that
it does not, that it work like shell (without the
godawful syntax).  In shell, cat foo 2>&1 >/dev/null
sends stderr to stdout and discards stdout.
(In psudocode: stderr=stdout; stdout=/dev/null)
Likewise, cat foo >/dev/null 2>&1 discards
both stderr and stdout. (stdout=/dev/null; stderr=stdout)

Regards syntax:

It seems cleanest to make the syntax involved in redirection of stderr
look (almost) like redirection of stdout.  And likewise
redirecting stdout should look like redirecting stderr.
The latter would then allow the semantics of redirecting
stdout to wherever stderr is going, without having to
re-specify exactly where stderr has been sent.

I don't have a good sense of what you're proposing regards using
a '\o&' type of syntax.  (But see below.)  Please elaborate if you'd
like me to pursue this direction.

My thoughts are having a \e command that would look
like \o.

So:

\o file   stdout to file
\o |prog  stdout to pipe
\oe       stdout to wherever stderr is going
\o        stdout to /dev/stdout

\e file   stderr to file
\e |prog  stderr to pipe
\eo       stderr to wherever stdout is going
\e        stderr to /dev/stderr

The above seem to be the semantic permutations the syntax needs to
handle.  It would be nice to be able to not have to
introduce a new \ command, but I can't think of a clear
way to shoehorn stderr into \o.  The best I can
come up with, based on your & idea, is something like:
(Text enclosed in [] is optional.)

\o[o][&] file   stdout to file
\o[o][&] |prog  stdout to pipe
\o[o]&e         stdout to wherever stderr is going
\o[&]           stdout to /dev/stdout
\o[&o]          stdout to wherever stdout is going (noop)

\oe[&] file     stderr to file
\oe[&] |prog    stderr to pipe
\oe&o           stderr to wherever stdout is going
\oe[&]          stderr to /dev/stderr
\oe[&e]         stderr to wherever stderr is going (noop)

It seems cluttered.  And the & seems redundant.
Without & it looks like:

\o[o] file   stdout to file
\o[o] |prog  stdout to pipe
\o[o]e       stdout to wherever stderr is going
\o           stdout to /dev/stdout

\oe file     stderr to file
\oe |prog    stderr to pipe
\oeo         stderr to wherever stdout is going
\oe          stderr to /dev/stderr

I suppose it's also possible to do as shell
does and (probably with & as a syntax token) be
able to use file descriptor numbers directly.
It's not clear to me where the win is in doing that.

Would you be thinking & introduces additional syntax?:

\o[&[o[>]]] file   stdout to file
\o[&[o[>]]] |prog  stdout to pipe
\o&[o]>e           stdout to wherever stderr is going
\o[&[o[>]]]        stdout to /dev/stdout

\o&e[>] file       stderr to file
\o&e[>] |prog      stderr to pipe
\o&e>o             stderr to wherever stdout is going
\o&e[>]            stderr to /dev/stderr

What sort of future extensibility do we get by
adding syntax to \o as opposed to adding a new command?

I'm unclear on how extending \o would fit in with --output.
(Adding a new \e command would seemingly involve adding
a new command line option.)

Thanks for the help.


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."                -- Robert A. Heinlein