Improve accuracy of ON_ERROR_STOP documentation.

Per a gripe from Tom Lane.
This commit is contained in:
Robert Haas 2011-06-14 11:05:54 -04:00
parent 85ea93384a
commit c3ad1e8dbd
1 changed files with 10 additions and 12 deletions

View File

@ -2770,18 +2770,16 @@ bar
<term><varname>ON_ERROR_STOP</varname></term> <term><varname>ON_ERROR_STOP</varname></term>
<listitem> <listitem>
<para> <para>
By default, if non-interactive scripts encounter an error, such By default, command processing continues after an error. When this
as a malformed <acronym>SQL</acronym> command or internal variale is set, it will instead stop immediately. In interactive mode,
meta-command, processing continues. This has been the <application>psql</application> will return to the command prompt;
traditional behavior of <application>psql</application> but it otherwise, <application>psql</application> will exit, returning
is sometimes not desirable. If this variable is set, script error code 3 to distinguish this case from fatal error
processing will immediately terminate. If the script was called conditions, which are reported using error code 1. In either case,
from another script it will terminate in the same fashion. If any currently running scripts (the toplevel script, if any, and any
the outermost script was not called from an interactive other scripts which it may have in invoked) will be terminated
<application>psql</application> session but rather using the immediately. If the toplevel command string contained multiple SQL
<option>-f</option> option, <application>psql</application> will commands, processing will stop with the current command.
return error code 3, to distinguish this case from fatal error
conditions (error code 1).
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>