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