Re: Add SHELL_EXIT_CODE to psql

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Add SHELL_EXIT_CODE to psql
Дата
Msg-id CAMsGm5c3+yLVnSkqb71rnCrMjjNMPGa=qSvf3z3E8Zyr-vYX8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add SHELL_EXIT_CODE to psql  (Corey Huinker <corey.huinker@gmail.com>)
Ответы Re: Add SHELL_EXIT_CODE to psql  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers
On Sat, 31 Dec 2022 at 16:47, Corey Huinker <corey.huinker@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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Add SHELL_EXIT_CODE to psql
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: wake up logical workers after ALTER SUBSCRIPTION