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.