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