At 11:53 PM 10/15/02 +0200, Arno Brinkman wrote:

>Hi, Jim
>
>> 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.
>
>Do you mean complete destroy the BLR part or do you mean let only
>the DSQL part ignore the BLR part ?
>This opens easier ways of implementing new DSQL features also!
>

Let the DSQL part ignore the BLR part. There is no reason to
remove, disable, or even change the BLR implementation, which
is absolutely required for backwards compatibility.

BLR (binary language representation), for the uninitiated, is a byte
encoded, message based, representation of database logic. Unlike
SQL, it represented in Polish. BLR is designed for machine
generation; as far as I know there has been only one hand coded
BLR request. BLR can be "parsed" with no more than a recursive
case statement.

A BLR request contains zero or more message declarations and
a language tree. The primary verbs are:

send -- Send a structured message of given type to the client
receive -- Block pending receipt of a structure message of given
type from the client
for -- Iteration through a described recordset executing
a given substatement for every record.
assignment
store
modity
erase
if

It's squeeky clean -- no precedence, no ESP, nothing but nested
<verb><argument>...

The mapping from BLR to the execution tree is straightforward.
But since BLR was originally designed to support SQL semantics,
and the execution tree designed to support BLR semantics, generating
execute tree directly from the SQL compiler should be piece of
cake.

And, yes, new SQL features could be implemented without extending
BLR. BLR would become, has dubya would say, irrelevant. It
just wouldn't bomb Iraq.


Jim Starkey