On Sat, Dec 31, 2022 at 5:28 PM Isaac Morland <isaac.morl...@gmail.com> wrote:
> On Sat, 31 Dec 2022 at 16:47, Corey Huinker <corey.huin...@gmail.com> > wrote: > >> >>> I wonder if there is value in setting up a psql on/off var >>> SHELL_ERROR_OUTPUT construct that when set to "off/false" >>> suppresses standard error via appending "2> /dev/null" (or "2> nul" if >>> #ifdef WIN32). At the very least, it would allow for tests like this to be >>> done with standard regression scripts. >>> >> >> Thinking on this some more a few ideas came up: >> >> 1. The SHELL_ERROR_OUTPUT var above. This is good for simple situations, >> but it would fail if the user took it upon themselves to redirect output, >> and suddenly "myprog 2> /dev/null" works fine on its own but will fail when >> we append our own "2> /dev/null" to it. >> > > Rather than attempting to append redirection directives to the command, > would it work to redirect stderr before invoking the shell? This seems to > me to be more reliable and it should allow an explicit redirection in the > shell command to still work. The difference between Windows and Unix then > becomes the details of what system calls we use to accomplish the > redirection (or maybe none, if an existing abstraction layer takes care of > that - I'm not really up on Postgres internals enough to know), rather than > what we append to the provided command. > > Inside psql, it's a call to the system() function which takes a single string. All output, stdout or stderr, is printed. So for the regression test we have to compose a command that is OS appropriate AND suppresses stderr.
