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 <k...@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
