On 15 Oct 2002 at 10:47, Jim Starkey wrote:

> 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.

We (royal we here), would need to rewrite the SQL compiler, not sure how much
work that would be, I haven't seen the code, and downloading the source is a major
drag at 48K.

> 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.

It's an issue of, might as well as, it's all ripped apart anyway, and changing some of
the data structures might lower the PITA factor, rather then doing something in a
goofy manner, clean up the data structure and do it the way it should be done.