> It is not "just decision". Doing commit/rollback inside SP simply
> makes no sense.

That is perhaps a FB-centric view. Oracle SP's do support
COMMIT/ROLLBACK in PL/SQL.

Like our DSQL, PL/SQL started our as a client-side tool, used in the
Oracle Forms package. Client scripts coded in PL/SQL could do COMMIT
and ROLLBACK and this made sense.

Later, PL/SQL was added to the server (version 7, I think) and
clients could use a shared libarary of SP's. Although they ran on the
server, logically they were still "between" the client and the
relational engine. Things still make sense.

Later again, it became possible to call stored functions
(including 'table functions', which are similar to our 'selectable
procedures') from a SQL statement. Now the SP runs logically "behind"
the relational engine and COMMIT/ROLLBACK does not make sense
anymore. Hence, this usage is blocked in Oracle and results in an
error.

In FB, the SP execution engine is the same as the relational
execution engine and the concept of "between" and "behind" are not
meaningful, so it seems that COMMIT/ROLLBACK never make sense.

Oracle-mode Firebird adds a separate execution engine for SP's and it
supports COMMIT/ROLLBACK in cases where the client directly calls the
SP ("between" usage). The code issues a commit/rollback_retaining
command, so the client's transaction context remains valid.

Paul