Re: Add SHELL_EXIT_CODE to psql

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Add SHELL_EXIT_CODE to psql
Дата
Msg-id CADkLM=d7H=E_P0gUqgyiBWUUzkL4gx9rQykjKWes8ZuiEFW=EQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add SHELL_EXIT_CODE to psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add SHELL_EXIT_CODE to psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Mar 20, 2023 at 1:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.com> writes:
> 128+N is implemented.

I think this mostly looks OK, but:

* I still say there is no basis whatever for believing that the result
of ferror() is an exit code, errno code, or anything else with
significance beyond zero-or-not.  Feeding it to wait_result_to_exit_code
as you've done here is not going to do anything but mislead people in
a platform-dependent way.  Probably should set exit_code to -1 if
ferror reports trouble.

Agreed. Sorry, I read your comment wrong the last time or I would have already made it so.
 

* Why do you have wait_result_to_exit_code defaulting to return 0
if it doesn't recognize the code as either WIFEXITED or WIFSIGNALED?
That seems pretty misleading; again -1 would be a better idea.

That makes sense as well. Given that WIFSIGNALED is currently defined as the negation of WIFEXITED, whatever default result we have here is basically a this-should-never-happen. That might be something we want to catch with an assert, but I'm fine with a -1 for now.
 
Вложения

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

Предыдущее
От: Ted Toth
Дата:
Сообщение: Re: [PATCH] Add <> support to sepgsql_restorecon
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Commitfest 2023-03 starting tomorrow!