On 10/15/10 20:05, Dimitry Sibiryakov wrote:

> 15.10.2010 17:57, Alex Peshkoff wrote:
>> On 10/15/10 19:09, Dimitry Sibiryakov wrote:
>>> 15.10.2010 16:59, Alex Peshkoff wrote:
>>>> What we started to discuss is 'Is the fact that isc_dsql_execute()
>>>> agrees to work with EXECUTE PROCEDURE a bug or documented behavior?'
>>> And everybody except Jim agreed that this is a bug.
>> Documented bug becomes feature :-)
> Bug in documentation shouldn't be considered as a specification for development. ;-)
>

Bug or not bug - but this is a way API worked since SPs' arrival. I do
not see serious (i.e. required to fix something more important) reasons
to change it's behavior.

>>> However, in this case one question left: what if the procedure is selectable (i.e. uses
>>> SUSPEND)? Shouldn't in this case all records be fetched before end-of-data and EXECUTE
>>> PROCEDURE to be effectively the same as SELECT?
>> No.
> Why not? It would bring our syntax a bit closer to MS SQL without loosing standard
> conformation.
>

EXECUTE PROCEDURE is parsed as special kind of SQL operator, which (if
user thinks about roundtrips) must be executed with special API call.
Imagine that call used in a case when multiple rows should be returned.
May be it's possible to fetch more rows from such statement, but how can
used know, should he do it or not? Moreover, to get an idea about it,
statement start to execute. All together all this looks far not good for me.