At 02:05 PM 10/15/2002 -0400, pschmidt@... wrote:

>We (royal we here), would need to rewrite the SQL compiler, not sure how much
>work that would be,

Not a huge amount. In fact, there's only one module in DSQL
that would need significant changes and that is gen.c - the blr
generator. The intermediate structures are fine and can easily
hold the semantic information necessary to generate the first
stage of the execution tree.

>I haven't seen the code, and downloading the source is a major
>drag at 48K.

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

Err.... maybe not the right choice of words. The data structures are
pretty much OK - we're just going through an unnecessary intermediate
step. For those of you who haven't been intimate with InterBase internals
since infancy, here's the history of DSQL. For the seriously uninitiate,
DSQL is dynamic sequel (that's another discussion), which allows queries
to be generated on the fly. The assumption when InterBase and its
predecessors were designed was that all dynamic code generation would
be done by high level tools.

1984. Don't have it, don't want it. That's what BLR is good for. If
you want dynamic queries, write a blr generator.

1985. Somebody pays us to implement DSQL. It runs on the client and
generates BLR and low-level API calls.

1987. Somebody notices that client/server applications really suffer
with DSQL because the client needs lots of metadata to support
BLR generation, so a simple query turns into a full-fledged
conversation between client and server.

1990. DSQL moves to the server side, but as a separate library (I think)
still generating BLR and low-level API calls.

Since then DSQL has been nudging its nose into the tent, but the relationship
has never been formalized.






Regards,

Ann
www.ibphoenix.com
We have answers.