On Wed, Jan 30, 2019 at 6:38 PM Kyotaro HORIGUCHI <horiguchi.kyot...@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.
