Subject | Re: [IB-Architect] RE: Classic vs. superserver (long, very very long) |
---|---|
Author | pschmidt@interlog.com |
Post date | 2002-10-15T21:38:39Z |
On 15 Oct 2002 at 16:19, Ann W. Harrison wrote:
mostly not sure what people have done to it, since Jim wrote it, it wouldn't take
much for someone at a certain software company to take a nice simple, well
working mechanism and totally FUBAR it.
Thanskgiving the 2nd Monday of October, after all parts of this country will be in the
deep freeze in another month).
but most people who work with systems like Firebird, have never used it, and some
probably are wondering what it is (me included).
> At 02:05 PM 10/15/2002 -0400, pschmidt@... wrote:Okay, I wasn't sure what was there, and how much of it needed to be changed,
>
>
> >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.
mostly not sure what people have done to it, since Jim wrote it, it wouldn't take
much for someone at a certain software company to take a nice simple, well
working mechanism and totally FUBAR it.
> >I haven't seen the code, and downloading the source is a majorI figured as much, after all it's logically Monday around here (Canada has
> >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.
Thanskgiving the 2nd Monday of October, after all parts of this country will be in the
deep freeze in another month).
>Maybe its time it was formalized, not saying that BLR doesn't have it's advantages,
> 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.
>
but most people who work with systems like Firebird, have never used it, and some
probably are wondering what it is (me included).