Re: [HACKERS] psql and libpq fixes

On Thu, 10 Feb 2000, Brian E Gallew wrote:

> Then <tgl@sss.pgh.pa.us> spoke up and said:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> This does bring up a thought --- should psql's kill-the-script-on-error
> > >> option perhaps zap the script only for errors committed outside of a
> > >> transaction block?
> > 
> > But on third thought, probably the thing that would be really useful
> > for "expected errors" is if there is a backslash-command that turns on
> > or off the kill-on-error behavior.  (The command line switch would
> > merely set the initial state of this flag.)  This way, a script could
> > use the option in an intelligent fashion:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

> 
> Urhm, wouldn't a better idea be to have something like Ingres' "ON
> ERROR" and "ON WARNING" settings?  In Ingres esqlc, you can create
> functions and then tell Ingres to execute them in the even of a
> warning or error.  Also, you can say "ON ERROR CONTINUE" and errors
> will then be returned to the application as a status, but otherwise
> ignored.

That's very nice and all, but psql doesn't work that way. I'm not sure how
other dbs organize their front-end internally, but that sort of scheme
would really take psql places we might not want it to go, and for which it
hasn't been designed -- namely, to be a programming language.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden