On 12/09/2012 03:58:26 PM, Karl O. Pinc wrote:
> Hi Alastair,
>
> On 12/09/2012 02:13:32 PM, Alastair Turner wrote:
> > - 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.
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 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.)
And oh yes, \e won't work as a command since it's already
taken. Since this is only an issue if \o is not overloaded
I await your review.
Thanks for the help.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
