Jim,

I would be quite happy with such a change, because as far as I can
tell at first glance, I would greatly simplify my code (support for
other SQL variants and multiple procedural engines). Considering we
have some quite divergent ideas about how the executor inside the
engine should be laid out, if this proposal makes life easier in both
world views, it must be quite sound.

> There would be, over time, three implementations of the interface.
> One, inside the engine, would be used in modules to replace the
> existing pre-processed modules (met, dfw, ini, etc). Once
> complete, the engine could be build without preprocessor.

Hmmm... This means that the engine will use SQL strings inside. These
must be compiled and compiling SQL is more expensive than compiling
BLR. Hence, the caching of "compiled requests" (or better, "prepared
statements" in the new model) becomes even more important. As I noted
in a previous post, I think that this caching code around queries
obfuscates code flow in the current engine code.

What are your thoughts? Keep caching code around actual queries, as
now? Put some chaching mechanism in the PreparedStatement class? Rely
on a db-wide SQL string cache, as you proposed in an earlier post?
Something different still?

Paul