> A modest proposal: We add a new field RDB$PROCEDURE_TYPE. A type 0
> procedure is unknown (for backwards compatibility). A type 1 procedure
> is a pseudo-table. A type 3 procedure is one that return discrete
> values rather than a record set. The procedure compiler sets
> RDB$PROCEDURE_TYPE to 1 if it sees a suspect, otherwise it sets it to 2.

SUSPEND you mean, not suspect ?

> If someone wants to get cute and put a suspend where it doesn't belong,
> he will get something unpredictable, which is only justice.

How this differ from current situation ?

Now: if developer don't put SUSPEND and do SELECT he has no result
"which is only justice", imho

New: if developer put SUSPEND like this - IF(<false condition>) THEN SUSPEND
"he will get something unpredictable, which is only justice"

Where is solution ? In any case we don't declare that procedure must
have resultset. By the way - what is resultset ? Is empty set is valid resultset
?
I see 2 ways we can go :
a) JDBC will do SELECT from SP and Java developers will write right SP's
b) we invent declarative way to force SP to return not empty resultset and
raise error if SP don't return it, for example
CREATE PROCEDURE xxx (...) RETURNS (...) WITH RESULT
or even
EXECUTE PROCEDURE xxx RETURNING ... WITH RESULT
but it seems ugly for me


Regards,
Vlad

PS Don't forget about side effect of SUSPEND - about internal savepoint