On Wed, Jan 30, 2019 at 6:38 PM Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> I guess the reason is that psql is widely used with just a single
> -c command and acutually the fix breaks the cases. So it doesn't
> seem back-pachable but it is apparently contradicting to
> documentation, which seems perfectly reasonable.
>
> So I propose to fix the behavior for 12 and back-patch
> documentation fix.
>
> | Exit Status
> |
> | psql returns 0 to the shell if it finished normally, 1 if a fatal
> | error of its own occurs (e.g. out of memory, file not found), 2
> | if the connection to the server went bad and the session was not
> | interactive, and 3 if an error occurred in a script and the
> | variable ON_ERROR_STOP was set.
> + As the only exception, irrespective of ON_ERROR_STOP setting,
> + psql returns 1 if the last executed command failed and it was
> + givin by -c option.
>
In head can we just turn ON_ERROR_STOP on by default when more than
one -c/-f is encountered, return 3, and call it a day. Then, if the
user unsets ON_ERROR_STOP and does the same have psql always returns 0
unless a file specified with "-f" cannot be found (or some other
application error...).
If so can we maybe reconsider having ON_ERROR_STOP off by default generally...
I don't like saying -c "is the same as a line in a script" since -c
requires complete statements (and doesn't share transactions with
other -c lines). Each -c simply provides psql with a single
auto-commit statement to execute - in the supplied order. If we need
a word here "procedure" might be a good choice.
David J.
