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 6099dfa71c
commit 6fdd897503

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>