> > 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.

> > ... and it even includes defaults, as in
> > EXECUTE BLOCK (a INTEGER = 10, b VARCHAR(10) = 'abc')
>
> No, EXECUTE BLOCK don't have default parameters, but stored
> procedures have it.
> If you need default parameters with EXECUTE BLOCK just use
> variables, i.e.
>
> EXECUTE BLOCK
> AS
> declare a INTEGER = 10;
> declare b VARCHAR(10) = 'abc';
> ...

Then perhaps so should be said in the Firedird roadmap document, which
now contains the following:

>EXECUTE BLOCK syntax
>Proposed Release: 2.0

>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.