> Where? My e-mail program sometimes junks good messages, but I
> didn't find that one even in the trash.

Here:

> Regardless of my own opinion about your request <g>, I see a few
> ways to help you.
>
> 1) Extend EXECUTE PROCEDURE to return a result set for selectable
> procedures.
>
> We're not MSSQL, so a single row will still be returned in PSQL (not
> an implicit cursor), so no problems here. I'd expect something like
> FOR EXECUTE PROCEDURE in PSQL to return a cursor, like we now do
> with EXECUTE STATEMENT. A simple SELECT will stay an optional way of
> doing this. But we have a problem with API - whether
> isc_info_sql_stmt_exec_procedure or isc_info_sql_stmt_select is
> going to be returned during prepare? Any of the answers will break
> the existing applications.

and here:

>> The problem is "how to know if you should use SELECT or EXECUTE
>> if you don't know anything about the procedure".

> This is not a client developer's problem. The engine returns this
> info since 1980s. The problem is how the engine should determine
> this to report correctly. There's no answer currently. There can
> be an answer if we can live with EXECUTE and SELECT returning
> different results, or with EXECUTE and CALL returning different
> results, or with EXECUTE and EXECUTE1 (knowing about user-declared
> procedure invokation type) returning different results. There's no
> other option, AFAIU.

But as I already wrote, this does not solve the problem, because the
isc_info_sql_stmt_type flag is available after preparing, that's too late.

Roman