> Firebird users generally not expect commit happening due to stored
> procedure call. Also procedure-level savepoint is needed to ensure
> statement atomicity. Both are needed to ensure proper handling of
> exceptions coming out of external procedures. At the same time some
> "batch" procedures may want to manipulate transaction context.

Agree

> To make this work I would create a special type of procedures
> AUTONOMOUS in Oracle terminology which execute in their own
> transaction context,control it and commit as often as they need
> without affecting global user context. This is what we can do
> without breaking existing model of statement exection and
> exception handling.

Agree. In my Oracle-mode work, I have allowed for autonomous
procedures that execute in their own transaction context. BTW, for
those interested, the Compiere-demo of Oracle-mode Firebird is
available from our ftp-site, ftp.janus-software.com/compiere

> PL/SQL is a different beast and will require some more work
> because it allows manipulating global transaction context and
> has completely different model of exception handling from what
> is used in Firebird now.

Disagree. PL/SQL is a different beast, but my understanding is that
PL/SQL procedures do NOT allow modifying the global transaction
context. Although the syntax allows for COMMIT and ROLLBACK, what
happens really is that an implicit savepoint is created at the entry
of a top-level procedure. COMMIT/ROLLBACK in the procedure body are
implemented effectively as commits/rollbacks to this implicit
savepoint.

> PL/SQL conceptually sits between the user and SQL engine and it
> will require some very careful througt to integrate into the
> engine. We do not want to repeat Microsoft mess they have with
> transaction control in procedures.

Agree: who needs a mess? I will be doing a talk on Oracle-mode
Firebird in Fulda and hope to think through the issues with the core
developers in the fringe of the conference.

Paul