From c3ad1e8dbd6cf1ff6d29bd2edb2da2c35187e768 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Tue, 14 Jun 2011 11:05:54 -0400 Subject: [PATCH] Improve accuracy of ON_ERROR_STOP documentation. Per a gripe from Tom Lane. --- doc/src/sgml/ref/psql-ref.sgml | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index eaf901d328..d77a1aa8f5 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2770,18 +2770,16 @@ bar ON_ERROR_STOP - By default, if non-interactive scripts encounter an error, such - as a malformed SQL command or internal - meta-command, processing continues. This has been the - traditional behavior of psql but it - is sometimes not desirable. If this variable is set, script - processing will immediately terminate. If the script was called - from another script it will terminate in the same fashion. If - the outermost script was not called from an interactive - psql session but rather using the - option, psql will - return error code 3, to distinguish this case from fatal error - conditions (error code 1). + By default, command processing continues after an error. When this + variale is set, it will instead stop immediately. In interactive mode, + psql will return to the command prompt; + otherwise, psql will exit, returning + error code 3 to distinguish this case from fatal error + conditions, which are reported using error code 1. In either case, + any currently running scripts (the toplevel script, if any, and any + other scripts which it may have in invoked) will be terminated + immediately. If the toplevel command string contained multiple SQL + commands, processing will stop with the current command.