On Tue, Dec 18, 2018 at 05:13:40PM +0900, Kyotaro HORIGUCHI wrote: > $ psql postgres -v ON_ERROR_STOP=0 -f ~/work/y.txt ; echo $? > $ psql postgres -v ON_ERROR_STOP=0 < ~/work/y.txt ; echo $?
> c) psql postgres -v ON_ERROR_STOP=0 -c foo -c 'select 1'; echo $? > d) psql postgres -v ON_ERROR_STOP=0 -c 'select 1' -c foo; echo $? > > (c) returns 0 and (d) returns 1, but both return 1 when > ON_ERROR_STOP=1. > The attached second patch lets (c) and (d) behave the same as (a) > and (b). I don't think the behavior in the single command case should be changed: |[pryzbyj@database postgresql]$ ./src/bin/psql/psql ts -c FOO 2>/dev/null ; echo $? |1 |[pryzbyj@database postgresql]$ patch -p1 </tmp/0002-Unify-psql-s-behavior-on-c-with-scripts.patch |patching file src/bin/psql/startup.c |[pryzbyj@database postgresql]$ make >/dev/null |[pryzbyj@database postgresql]$ ./src/bin/psql/psql ts -c FOO 2>/dev/null ; echo $? |0 Also, unpatched v11 psql returns status of last command |[pryzbyj@database postgresql]$ psql ts -xtc 'SELECT 1' -c FOO 2>/dev/null ; echo $? |?column? | 1 | |1 patched psql returns 0: |[pryzbyj@database postgresql]$ ./src/bin/psql/psql ts -xtc 'SELECT 1' -c FOO 2>/dev/null ; echo $? |?column? | 1 | |0 I'd prefer to see the exit status of the -f scripts (your cases a and b) changed to 3 if the last command failed. I realized that's not what the documentation says so possibly not backpatchable. |3 if an error occurred in a script and the variable ON_ERROR_STOP was set. Think of: $ cat /tmp/sql begin; foo; select 1; $ psql ts -f /tmp/sql ; echo ret=$? BEGIN psql:/tmp/sql:2: ERROR: syntax error at or near "foo" LINE 1: foo; ^ psql:/tmp/sql:3: ERROR: current transaction is aborted, commands ignored until end of transaction block ret=0 I think ON_ERROR_STOP would control whether the script stops, but it should fail the exit status should reflect any error in the last command. The shell does that even without set -e. Justin