Adriano dos Santos Fernandes wrote:

> Em 9/2/2010 13:55, Jim Starkey escreveu:
>
>> It's a pity that the running aggregates got dropped. The ability to
>> print out a running count, running total, or running average was really
>> quite useful.
>>
>>
> For curiosity, what exactly they used to do?
>

An example (hopefully self-explanatory):

print running count, name, salary, running total salary, running
average salary of people

>
>> But back to BLR. The analogy to Java byte codes isn't off base, but BLR
>> doesn't provide the benefits of Java classes, which, primarily, is
>> portability. Firebird, Interbase, and Oracle Rdb are the only database
>> systems that every used BLR, and I doubt there is any compatibility
>> among these left. And since nothing but GPRE generates static BLR, the
>> language efficiency argument is long gone.
>>
>>
> Are you sure no other database engine store some sort of (pre)compiled
> command?
>

Sure, but not in an externally accessible form. Sybase, for example,
had a horribly slow compiler / optimizer, so they stored everything.
But the form was internal so they could change it when / if they got
smarter without invalidating user code.

Unless there is a pressing reason not to, it makes sense to pass
language constructs in the original language. Java uses byte codes
because it isn't desirable or practical to make the full compilation
environment available to the run time. But even Java has been all but
eliminated from Web pages by Javascript, which is compiled and
interpreted at the execution site.

>
>> I invented BLR to pass open ended semantics between client and server in
>> a computationally efficient manner when the VAX 780 roamed the earth,
>> workstations maxed out at 3 MB, and servers at 7MB. That was a
>> different era. What made sense then, doesn't make sense now. What
>> makes sense now is caching compiled SQL statements and procedures of the
>> server, and paying to cost to prepare then on demand. By leaving the
>> engine BLR bound, you make this impossible. So by sticking to
>> tradition, you're accepting a performance (both elapsed and latency)
>> that your competitors don't have. And it's all self-induced.
>>
>>
> But BLR is a (virtual) machine language. Only Firebird supports it, like
> only PPC machine could run PPC instructions. :-)
>

No, it isn't. It's a much higher level language. Machine language
don't have type independent operators, implicit joins, etc. It's syntax
is reverse Polish, but the semantics are a full bore programming
language with exception handling, local variables, looping constructs, etc.

> What I agree is that would be more simple to have post-parsed node
> hierarchy direct for engine needs than generate and parse BLR. But this
> does not seems a very complicated thing currently.
>

It isn't complicated. And it gets the precompiler out of the engine,
and would make it possible to upgrade system tables in place.

>
>> What does make sense is to leave BLR in place for backwards
>> compatibility and move the SQL into the engine. If you can't figure out
>> how to do this, look at Vulcan. Moving SQL into the engine will reduce
>> code size and complexity, sidestep all sorts of nasty meta-data issues,
>> and speed up the product.
>>
> Since Firebird 2.5, SQL is already supported in the engine. For example,
> when a database is created with a default character set and collation, a
> DSQL command is internally (no y-valve) sent and run.
>
>
> Adriano
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]