Samofatov, Nickolay 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.

If selectable proc doesn't return rows, this isn't an error. Is it an error
to do a SELECT from one table using a WHERE clause that will filter out all
records?

for select f from t where pk = :param
into :f_var do
begin
...
end;

What if t is empty or there's no pk matching param? This is a legitimate
empty result set.

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

If the proc doesn't have a suspend at all, then using it like a table is an
error. Probably will upset anyone, but what useful output can the developer
get now if he tries to select from a non-selectable stored proc. He will get
nothing without any explanations and without any hint the call syntax was
wrong. I tend to agree with stopping compilation here.

Having additional metadata to signal the type of the procedure is fine for
me. It's a small change, it's easy to detect when creating or altering the
procedure and doesn't change the current behavior; it only provides more
information in system tables. I don't understand why people put too much
effort to resist that little enhancement.

C.