Re: User control over psql error stream
От | Karl O. Pinc |
---|---|
Тема | Re: User control over psql error stream |
Дата | |
Msg-id | 1353562398.10996.2@mofo обсуждение исходный текст |
Ответ на | Re: User control over psql error stream (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: User control over psql error stream
|
Список | pgsql-hackers |
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? To look at it from another angle, you need it for the same reason you need \o -- to redirect output to multiple places from within a single psql process. \o redirects stdout, but I'm interested in redirecting stderr. Which makes me think that instead of a \pset option a, say, \e, command is called for. This would do the same thing \o does only for stderr instead of stdout. The problem comes when you want \e to send to the same place \o sends to, or vice versa. You can't just compare textual paths because there's more than one way to write a path to an object in the filesystem. You need either a "special" argument to \e and \o -- very ungood as it breaks backwards compatibility with \o -- or you need, perhaps, yet another \ command to send stderr to where \o is going or, conversely, send \o to where stderr is going. Perhaps\oe could send \o output to where stderr is going at the moment and \eo could send stderr output to where \o output is going at the moment? Sorry to ramble on. I'm tired. Regards, Karl <kop@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
В списке pgsql-hackers по дате отправления: