psql's ON_ERROR_STOP is misdocumented

Started by Tom Lanealmost 15 years ago6 messagesdocs
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

The documentation for ON_ERROR_STOP states, or at least implies by
omission, that it only affects the behavior in non-interactive scripts:

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 -f option, psql will return error
code 3, to distinguish this case from fatal error conditions
(error code 1).

However, it is easily proven that it *does* affect interactive commands;
just try two commands on one line:

regression=# select 1/0; select 2;
ERROR: division by zero
?column?
----------
2
(1 row)

regression=# \set ON_ERROR_STOP 1
regression=# select 1/0; select 2;
ERROR: division by zero
regression=#

Can we get the docs changed to reflect reality?

regards, tom lane

#2Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#1)
Re: psql's ON_ERROR_STOP is misdocumented

On Thu, May 5, 2011 at 11:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The documentation for ON_ERROR_STOP states, or at least implies by
omission, that it only affects the behavior in non-interactive scripts:

       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 -f option, psql will return error
       code 3, to distinguish this case from fatal error conditions
       (error code 1).

However, it is easily proven that it *does* affect interactive commands;
just try two commands on one line:

regression=# select 1/0; select 2;
ERROR:  division by zero
 ?column?
----------
       2
(1 row)

regression=# \set ON_ERROR_STOP 1
regression=# select 1/0; select 2;
ERROR:  division by zero
regression=#

Can we get the docs changed to reflect reality?

Here's an attempt at some suitable word-smithing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachments:

on-error-stop.patchapplication/octet-stream; name=on-error-stop.patchDownload+10-12
#3Robert Haas
robertmhaas@gmail.com
In reply to: Robert Haas (#2)
Re: psql's ON_ERROR_STOP is misdocumented

On Mon, Jun 13, 2011 at 11:01 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, May 5, 2011 at 11:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The documentation for ON_ERROR_STOP states, or at least implies by
omission, that it only affects the behavior in non-interactive scripts:

       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 -f option, psql will return error
       code 3, to distinguish this case from fatal error conditions
       (error code 1).

However, it is easily proven that it *does* affect interactive commands;
just try two commands on one line:

regression=# select 1/0; select 2;
ERROR:  division by zero
 ?column?
----------
       2
(1 row)

regression=# \set ON_ERROR_STOP 1
regression=# select 1/0; select 2;
ERROR:  division by zero
regression=#

Can we get the docs changed to reflect reality?

Here's an attempt at some suitable word-smithing.

Hearing no objections, committed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#4Josh Kupershmidt
schmiddy@gmail.com
In reply to: Robert Haas (#3)
Re: psql's ON_ERROR_STOP is misdocumented

On Tue, Jun 14, 2011 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Hearing no objections, committed.

s/variale/variable

Josh

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#3)
Re: psql's ON_ERROR_STOP is misdocumented

Robert Haas <robertmhaas@gmail.com> writes:

Hearing no objections, committed.

Looking at this a second time, it needs spell-checked. "variale"?

regards, tom lane

#6Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#5)
Re: psql's ON_ERROR_STOP is misdocumented

On Tue, Jun 14, 2011 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Hearing no objections, committed.

Looking at this a second time, it needs spell-checked.  "variale"?

Picky, picky. You say potato, I say potatoe.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company