Dmitry,

> > I agree. It would be nice to have procedure type flag
> computed by the
> > engine based on presence of SUSPEND statement in there.
> > If EXECUTE PROCEDURE is called on "selectable" SP it may return
> > resultset.
>
> Let me see whether I got this thing right.
>
> 1) RDB$PROCEDURE_TYPE is introduced and calculated by the engine

Yes.

> 2) Client-side EXEC PROC is described as either select or
> execute depending on this value

Yes. This way access layer may decide if it wants to hide the difference
between executable and selectable procedures or not.

> 3) Since we don't have cursor datatypes, PSQL EXEC PROC needs
> an iteration extention (e.g. FOR EXEC PROC)
> 4) FOR EXEC PROC is not allowed for non-suspend procedures
> 5) PSQL simple EXEC PROC behaves like now (don't care about
> the new type
> value)

No, I have slightly different opinion regarding EXECUTE PROCEDURE
handling in PSQL code.

3) EXECUTE PROCEDURE remains singleton construct and works either with
executable SP or singleton selectable SP.
If selectable SP does not return rows or returns more than one row we
need to handle it according to standard logic, basically raise exception
in both cases.

4) SELECT should only work with selectable SP and should not compile if
you attempt to use it with executable SP.

5) I do not see the special need for FOR EXECUTE PROCEDURE iteration
construct, FOR SELECT may be used instead. But if we want it (for
example, due to Codd's orthogonality reasons) we may add it as an alias
to FOR SELECT and generate the same BLR as if you wrote SELECT * FROM
<proc_name>.

This way we add consistency and guard against programmer mistakes, but
also preserve compatiblity with existing correct user code.

> Dmitry

Nickolay