Re: Add SHELL_EXIT_CODE to psql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add SHELL_EXIT_CODE to psql
Date
Msg-id 1352067.1679418608@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add SHELL_EXIT_CODE to psql  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Add SHELL_EXIT_CODE to psql  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
Corey Huinker <corey.huinker@gmail.com> writes:
> On Mon, Mar 20, 2023 at 1:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * 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.

Good point.  So we'd better have it first pass through -1 literally,
else pclose() or system() failure will be reported as something
misleading (probably signal 127?).

Pushed with that change, some cosmetic adjustments, and one significant
logic change in do_backtick: I made it do

    if (fd)
    {
        /*
         * Although pclose's result always sets SHELL_EXIT_CODE, we
         * historically have abandoned the backtick substitution only if it
         * returns -1.
         */
        exit_code = pclose(fd);
        if (exit_code == -1)
        {
            pg_log_error("%s: %m", cmd);
            error = true;
        }
    }

As you had it, any nonzero result would prevent backtick substitution.
I'm not really sure how much thought went into the existing behavior,
but I am pretty sure that it's not part of this patch's charter to
change that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Transparent column encryption
Next
From: Robert Haas
Date:
Subject: Re: CREATE DATABASE ... STRATEGY WAL_LOG issues