Subject | Extending SP lang. to ISQL |
---|---|
Author | Paul Reeves |
Post date | 2000-05-13T07:32:23Z |
ISQL provides a powerful way of creating and maintaining databases via scripts.
However it suffers from two shortcomings. One is the lack of implicit
blob<>string conversion. This subject has been dealt with at length, so I don't
propose to dwell upon it. Suffice to say that the ability to maintain the
rdb$description columns via scripts would be useful.
The other lack is that of simple language constructs such as if..then..else or
while..do. Deploying a script to upgrade a database is rendered unnecessarily
complex by this lack. It would be nice to be able to test if objects exist prior
to attempting to drop them, for instance. Presently it is necessary to carefully
check error log files to see what has gone wrong and why and whether it is a
critical error, or benign (such as trying to drop a non-existent object).
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?
I know there are already lots of scripting languages out there and I don't
propose that we try to write another. It may even be that most people just use
an existing scripting language to call isql with the necessary parameters. In
some ways this is probably adequate, except that it is not a cross-platform
solution. IAC, the main thing I need is just to be able to declare some
variables and do some if..then..else tests. The current capabilities of the SP
language, combined with the existing SQL capabilities would be enough.
An easy solution to this problem would be to allow SPs to execute DDL. The
reason for this limitation escapes me, but it is probably a good one.
Paul
--
Paul Reeves
Fleet River Software
However it suffers from two shortcomings. One is the lack of implicit
blob<>string conversion. This subject has been dealt with at length, so I don't
propose to dwell upon it. Suffice to say that the ability to maintain the
rdb$description columns via scripts would be useful.
The other lack is that of simple language constructs such as if..then..else or
while..do. Deploying a script to upgrade a database is rendered unnecessarily
complex by this lack. It would be nice to be able to test if objects exist prior
to attempting to drop them, for instance. Presently it is necessary to carefully
check error log files to see what has gone wrong and why and whether it is a
critical error, or benign (such as trying to drop a non-existent object).
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?
I know there are already lots of scripting languages out there and I don't
propose that we try to write another. It may even be that most people just use
an existing scripting language to call isql with the necessary parameters. In
some ways this is probably adequate, except that it is not a cross-platform
solution. IAC, the main thing I need is just to be able to declare some
variables and do some if..then..else tests. The current capabilities of the SP
language, combined with the existing SQL capabilities would be enough.
An easy solution to this problem would be to allow SPs to execute DDL. The
reason for this limitation escapes me, but it is probably a good one.
Paul
--
Paul Reeves
Fleet River Software