Subject RE: [Firebird-Architect] Re: RFC: Please unify stored procedure execution
Author Claudio Valderrama C.
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

for select f from t where pk = :param
into :f_var do

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.