Jim,

> I don't understand what the problem is. A thin DSQL layer might not
> have any idea of what a particular SQL string might do under after the
> statement is executed. If it produces results, then it can use
> isc_dsql_fetch to get them. Expecting a command line interpreter to do
> a semantic analysis of a user supplied string is a little harsh...

All the required semantic analysis is to ask the prepared statement for
its type and check whether it's isc_info_sql_stmt_exec_procedure. If so,
call isc_dsql_execute2() instead of isc_dsql_execute(). This is what our
poor ISQL has been doing since the very beginning.

> That aside, does it really make sense to remove documented functionality
> because it offends your sensibilities?

The problem is that it doesn't work as documented. The API guide says
that if isc_dsql_execute2() is called without output sqlda, then a
result set is created and you need to call isc_dsql_fetch() to read the
values from the result set. Sounds logical. However, in fact, a result
set (aka cursor) is never created for EXECUTE PROCEDURE. The statement
pretends to look like a cursor and allows you one and only one fetch.
After that you'll be getting unexpected runtime errors. If you want to
avoid these errors, you should be clever enough and look at the
statement type in advance. So the minimal semantic analysis seems to be
required anyway.

Maybe it's just me, but I see a problem asking for a solution here
(read: it offends my sensibilities). And I have a feeling that fixing
the code to be in sync with the documentation (i.e. create a cursor for
such statements) is wrong in this particular case. Hence a call for
opinions.


Dmitry