The fundamental problem with the external procedure proposal is that it
doesn't adequately address communication between the engine and the
external procedure facility. The primary issue is how the external
procedure performs database access. It appears that the intention is
for the external procedure to use the client API, though this isn't
explicitly stated. If so, it can't work without breaking the layering.
The root of the problem is that for the procedure to operate as part of
the client's transaction it needs a Y-valve transaction handle which is
not known inside the engine. Worse, in Vulcan, it is inacessable to the
engine. I suspect that the trial implementation grubbed around inside
of the Y-valve code. If so, this is a serious violation of the Firebird
architecture and is unsupportable in the future.

An alternative implementation involving the export of engine calls and
data structures is, if possible, worse since the class and data
structures are highly version specific.

The solution to the problem is already in place due to early and
effective lobbying by Paul Ruizendaal: the InternalConnection class
implementation of the Connection interface. This mechanism was invented
for the explicit purpose of exporting database semantics and context to
external procedures. An InternalConnection object is obtained by the
internal engine method Attachment::getUserConnection(Transaction*). The
connection object provides a clean, architecturally supportable
interface to internal engine functions using the JDBC paradigm.