At 12:15 AM 5/27/01 -0400, Claudio Valderrama C. wrote:

>> Hey, fella, BLR wasn't designed to be user friendly. It was designed
>> to be cheap to generate and cheaper to rip apart. You give a field
>> name a left and BLR is going to believe you had an inkling of what
>> you are doing. Don't blame BLR, dump it.
>
>Jim, you are suggesting to change the motor of the vehicle. What do we have
>after getting rid of the motor? A skeleton? What thing should a BLR
>replacement do instead of the current behavior?
>

Gee, I was afraid nobody would ask.

I'm suggesting that SQL be integrated into the engine. It would
eliminate the separate-but-inequal DSQL meta-data stash, semantic
mismatch between SQL and BLR, and enable compiled statement caching
(in my humble opinion, a very big win).

The switcheroo would not be nearly as radical as it appears. There
are three execution mechanisms: Expression evaluation, Record streams,
and statement execution. The first two would be unchanged, which
means most of the request compiler and all of the optimizer (sic)
would be unchanged. A new statement execution mechanism would
mirror SQL verbs (select, insert, update, delete), and could
depend on threads rather than threaded interpretation. The VIO
and DPM layers would be untouched. There is no reason that the
two statement engines couldn't co-exist for backwards compatibility.

Moving SQL into the engine would also enable "native" DDL handling,
backing away from active system table (which seemed like a good
idea at the time...).

Jim Starkey