Обсуждение: psql's ON_ERROR_STOP is misdocumented
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
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
Вложения
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
On Tue, Jun 14, 2011 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote: > Hearing no objections, committed. s/variale/variable Josh
Robert Haas <robertmhaas@gmail.com> writes:
> Hearing no objections, committed.
Looking at this a second time, it needs spell-checked. "variale"?
regards, tom lane
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