Jim,

Thank you for taking part and lifting the focus of the discussion to
a very architectural level. However, your message is a bit too terse
for my feeble mind. I would appreciate a bit of elaboration.

> The right way to implement PL/SQL is an interpreter sitting

parallel to

> but separate from looper that implement PL/SQL semantics.

Yes, that is my current conclusion too: I wasn't satisfied with what
BLR/looper could do for my needs and hence I did a parallel
interpreter. JVM would be another kind of parallel interpreter.

> The runtime is structured with three independent mechanisms.

Record

> streams are handled with a very general polymorphic RSB mechanism;
> boolean and value expressions are handled by a recursive EVAL

mechanism,

> and BLR semantics are handled by a painfully tortuous "looper"

designed

> to allow a statement to stall in a non-threaded environment.

I don't understand from 'designed' onwards. Please explain a bit if
more than casually relevant.

> Looper, in
> turn, calls on the VIO (virtual I/O) layer to do all actual

database

> work. A PL/SQL (and/or a proper SQL) execution engine could

exploit the

> existing EVL and RSB mechanisms while providing an alternative path

the

> to very clean VIO layer. There is no reason to extend BLR (which

is

> akin to extending the dodo) when an relatively simple and more

efficient

> alternative engine would do the trick.

Hmmm. This sounds to me as you recommend a single interpreter. The
first line suggests recommending two parallel interpreters. I'm
confused now (which happens often & quickly :^) ).

Perhaps you mean that RSB, EVL and VIO should work with two "ping-
pong-ing" interpreters, one for procedural code (eg. JVM, BTC,
whatever) and one for DML/DDL code (perhaps a trimmed form of the
current BLR, perhaps something a bit akin to the sqlite VDBE, but
more sophisticated - see http://www.hwaci.com/sw/sqlite/vdbe.html or
perhaps something different still)

I suppose 1 procedural engine should be native to the engine (to at
least support PSQL, but perhaps also PL/SQL). It would probably not
be all that hard to add an API for external engines, like a JVM or
external, compiled C/C++ procedures.

Please eleborate on the design direction you are proposing

> I strongly suggest that any attempt to extend BLR and looper to

support

> PL/SQL be abandoned forthwith and directly in favor an alternative
> execution engine using otherwise existing mechanisms.

A potent statement from a potent source. But how should I read it?
1. Stop thinking abour extending BLR and go for the separate
interpreter , or
2. Stop prototyping new directions until a rewrite of the internal
interpreter is done
Please elaborate.

Once again, thanks for your input and looking forward to more.

Paul