On Wed, Dec 28, 2022 at 5:59 AM Maxim Orlov <orlovmg@gmail.com> wrote:
Hi!
The patch is implementing what is declared to do. Shell return code is now accessible is psql var.
Overall code is in a good condition. Applies with no errors on master.
Unfortunately, regression tests are failing on the macOS due to the different shell output.
That was to be expected.
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.
2. Exposing a PSQL var that identifies the shell snippet for "how to suppress standard error", which would be "2> /dev/null" for -nix systems and "2> NUL" for windows systems. This again, presumes that users will actually need this feature, and I'm not convinced that they will.
3. Exposing a PSQL var that is basically an "is this environment running on windows" and let them construct it from there. That gets complicated with WSL and the like, so I'm not wild about this, even though it would be comparatively simple to implement.
4. We could inject an environment variable into our own regression tests directly based on the "#ifdef WIN32" in our own code, and we can use a couple of \gset commands to construct the error-suppressed shell commands as needed. This seems like the best starting point, and we can always turn that env var into a real variable if it proves useful elsewhere.
