From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add SHELL_EXIT_CODE to psql |
Date: | 2023-03-20 20:19:04 |
Message-ID: | CADkLM=d7H=E_P0gUqgyiBWUUzkL4gx9rQykjKWes8ZuiEFW=EQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 20, 2023 at 1:01 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Corey Huinker <corey(dot)huinker(at)gmail(dot)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.
Attachment | Content-Type | Size |
---|---|---|
v11-0001-Add-PG_OS_TARGET-environment-variable-to-enable-.patch | text/x-patch | 1.1 KB |
v11-0002-Add-wait_result_to_exit_code.patch | text/x-patch | 1.6 KB |
v11-0003-Add-psql-variables-SHELL_ERROR-and-SHELL_EXIT_CO.patch | text/x-patch | 7.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2023-03-20 20:20:38 | Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences |
Previous Message | Ted Toth | 2023-03-20 20:17:09 | Re: [PATCH] Add <<none>> support to sepgsql_restorecon |