> > > EXECUTE BLOCK (a INTEGER, b VARCHAR(10)) RETURNS (id INTEGER) AS
> > > BEGIN
> > > id = gen_id(my_generator, 1);
> > > INSERT INTO my_table (col_id, col_a, col_b) VALUES (:id, :a, :b)
> > SUSPEND;
> > !!! ;)
> oops...
> well, this gives some weight to a proposal to throw exception on
> SELECT from procedures without SUSPEND -- for I have made such mistake
> more than once.

EXECUTE BLOCK with outputs semantically fully equal to
SELECT * FROM stored procedure

...

> Then perhaps so should be said in the Firedird roadmap document, which
> now contains the following:
>
> >EXECUTE BLOCK syntax
> >Proposed Release: 2.0

Roadmap is not a documentation replacement, right ? ;)

> >Vlad Horsun and others are developing a syntax to allow DSQL
> execution of an unnamed >block of procedural language code, consisting
> of a BEGIN...END block headed by an <EXECUTE BLOCK statement.
> >Syntax pattern:
>
> >EXECUTE BLOCK [ (param datatype = ?, param datatype = ?, ...) ]
> > [ RETURNS (param datatype, param datatype, ...) } AS
> > [DECLARE VARIABLE var datatype; ...]
> > BEGIN
> > ...
> > END
>
> Notice the 'param datatype = ?' parts.

If you wish, you may read "doc\sql.extensions\README.execute_block"
which is available near the year :

http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/doc/sql.extensions/README.execute_block?view=markup

Since EXECUTE BLOCK is generated from client-side it's not needs
to have default parameters


Regards,
Vlad