|Subject||Re: RFC: Please unify stored procedure|
> Where? My e-mail program sometimes junks good messages, but IHere:
> didn't find that one even in the trash.
> Regardless of my own opinion about your request <g>, I see a fewand here:
> ways to help you.
> 1) Extend EXECUTE PROCEDURE to return a result set for selectable
> 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.
>> The problem is "how to know if you should use SELECT or EXECUTEBut as I already wrote, this does not solve the problem, because the
>> 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.
isc_info_sql_stmt_type flag is available after preparing, that's too late.