On 11/21/2012 01:41:56 PM, Peter Eisentraut wrote:
> On 11/15/12 3:53 PM, Karl O. Pinc wrote:
> > This patch gives the end user control over psql's
> > error stream. This allows a single psql session
> > to use \o to send both errors and table output
> > to multiple files. Useful when capturing test output, etc.
>
> What does this do that cannot in practice be achieved using shell
> redirection operators?
I've 3 answers to this. The short one, the long one,
and the practical one. Sorry to go on about it.
The brief generic answer is:
Easily capture error output associated with disparate
input streams, interspersed with the data output associated with
the disparate input streams, in separate files
correlated with the input, in the case where transactions
span multiple input streams. That latter
bit about transactions being the important part.
Of course I could be wrong/not clever enough.
The long generic answer is:
Shell redirection works fine if the transactions do not span
input streams; a separate connection/psql instance can
be used to redirect stderr intermixed with stdout as desired.
However when transactions span input streams then a single
psql instance/db connection is required to maintain
transaction state. In such a case it is difficult
to re-redirect stderr so that it's output appears
intermixed with table data output (stdout) in
time wise order while at the same time redirecting
all output into files that correlate with the
various input streams.
It's doable with something like:
psql 2>&1 < myfifo | mydemultiplexer &
where "myfifo" is a fifo fed the various input streams
and "mydemultiplexer" is a some process that
splits stdin into various output files as
various bits of input are sent to psql. But there
must be a way to communicate with the mydemultiplexer,
and you need to worry about synchronization of
input with output. And it's not clear to me how to
write mydemultiplexer in shell either.
Note that I've not actually tried the example above.
The practical answer is that I want my dependency
based test framework to work:
http://gombemi.ccas.gwu.edu/cgi-bin/darcsweb.cgi?r=gombemi;a=tree;f=/
db/test
For an intro see:
http://gombemi.ccas.gwu.edu/cgi-bin/darcsweb.cgi?
r=gombemi;a=headblob;f=/db/test/test.mk
I'm using this patch in my test framework.
If I had to I think I could get away
without it, but it would involve a bit of
work, and more than a bit of additional
complication.
Although I've got (much) further work to do
if I'm to follow through on my notion to
release this as a generic test framework,
what's documented in test.mk works. Probably.
(Not bad for under 300 lines of actual code,
comments excluded. Perhaps under 200 if you
eliminate blank lines and configuration for
my real-world use.)
Comments/suggestions are welcome.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
