"Vlad Horsun" <hvlad@...> wrote:

>
> > 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.
>
> This will break existing applications.

First, I'm don't think there are a lot of such applications. Second, if
RDB$PROCEDURE_TYPE is filled with NULL for migrated databases, then we could
easily add a compatibility code. The new behaviour will be introduced only
for recreated procedures and this should be properly documented. I'm going
to be satisfied as long as we allow a singleton selectable procedure to be
called with EXEC.

I still would prefer to avoid any changes, but if it's going to happen, then
I'm with Nickolay's solution.

> > 4) SELECT should only work with selectable SP and should not compile if
> > you attempt to use it with executable SP.
>
> This will break existing applications.

I agree with Martijn here. I cannot think of an _intentional_ logic to rely
on an empty set returned from a non-selectable SP.


Dmitry