The EXECUTE STATEMENT feature allows Firebird 1.5 procedures to execute
SQL constructed at runtime. It did not survive the transition from
Firebird to Vulcan. Reimplementing it with the new, internal engine SQL
processing should be reasonably straightforward.

In Firebird, the server is a single large image without clearly defined
boundaries. Vulcan is more modular, having a distinct server program, a
dispatch module, and providers that implement an architecturally stable
but private interface. In Firebird subsystems quite frequently call
into lower levels of the engine and in places, including EXECUTE
STATEMENT, lower levels of the engine call out. Neither of these
practices is possible with Vulcan.

On the other hand, Vulcan has a natural mechanism for handling SQL
generated at runtime with it's internal SQL. Using internal SQL avoids
the need for constructing all the mechanisms of DSQL, converting the
query into BLR, and reversing the process to bring results into the
procedure.

One of the side effects of the "loop-around" behavior of EXECUTE
STATEMENT is that dynamic SQL strings in procedures execute with the
client's privileges rather than the privileges of the procedures. It
has been argued that executing with the client's privileges is a feature
since the client is likely to have less access to tables than the
procedure. If a procedure were to execute an arbitrary statement,
entered at runtime - "delete from Customers", for example - the fact
that the procedure has write access to the Customers table would not
allow the client, who does not, to execute that destructive statement.

No doubt, Vulcan can emulate that behavior, but not straightforwardly,
and, in my opinion, not without considerable thought. The ability to
grant privileges to procedures, triggers, and views make Firebird
security much more discriminating than most SQL databases. The
possibility that a negligent programmer would allow a procedure to
execute arbitrary SQL from the user does not seem to justify breaking
that model for a useful feature like executing dynamic SQL in procedures.

The most common use of EXECUTE STATEMENT is in constructing WHERE
conditions from choices on a screen. A number of people who contribute
to the support list run applications that are entirely procedure driven.
Clients have no privileges beyond what they get by running the
procedures. Requiring such applications to grant client privileges for
the purpose of running a generated WHERE clause seems burdensome and
less secure than the alternative - running the dynamic SQL with the
procedure's privileges.

An underlying question is whether security exists to protect the
careless from themselves? A developer who allows procedures to execute
arbitrary SQL in an application with sophisticated security rules is
careless at best. Or do we want to make it possible to build systems
that use all the capabilities of the system together?

Regards,


Ann