At 07:54 AM 10/15/02 -0400, pschmidt@... wrote:

>
>Wouldn't ripping out BLR be a big ugly job? I haven't looked at the

current source,

>but I would think that it would mean re-writing the guts. Perhaps it's

getting like an

>old car, we are replacing the engine, transmission, and doing a whole

whack of

>body work, maybe it's time for a new car. I wonder if maybe we should

use the

>current implementations as the source for building a specification

document on a

>whole new engine, one that use fine grained locking multi-threading, SQL

as it's

>native language, and runs UDF's in a sandbox. We can keep the SQL syntax,

and

>disk structure and a good chunk of the API's.
>
>

Less than it would appear. BLR is compiled into an execution tree
which is then optimized. The SQL compiler could generate the same
execution tree, just skipping BLR generation and BLR parsing. Nothing
would require any change to the execution side.

Once you started, however, it would be tempting to extend the runtime
data structures to more closely model SQL semantics, but this would
be strictly optional.



Jim Starkey