>Given that InterBase already supports procedural language constructs in

stored

>procedures and triggers, and given that ISQL already has some capabilities

such

>as input, shell, set etc., how much work would be involved in extending it?

Is

>it practical? Is it useful?
>

Very useful. But what I'd really like is to have all the statements sent to
the server and processed there.

For operations on a remote computer, it is much more efficient to send a
whole bunch of statements and the logic of how and when to execute them,
than to send each statement, evaluating the result and then sending another
statment, etc. It's a matter of encapsulating everything in a single
message/script.

It also saves you the trouble of writing a program when you want to execute
a bunch of statements on a remote machine. Just mail the operator there the
script, have him execute it, and have the script report the results back to
him. When I want to do something like this today, I send a script (with
*very* simple flow logic) and a program to run it. It'd be a real plus to
have this on the database server itself.

Marcelo Lopez Ruiz