At 01:50 AM 5/16/00 -0400, Claudio Valderrama C. wrote:

>If Java is going to be bundled into the engine

Java gives us an opportunity to add a safe mechanism which is neither
exactly a stored procedure nor exactly a UDF, but has all the benefits
of both, except the simple language used for stored procedures. For
historic reasons, I doubt that we can eliminate UDF's in other languages,
however they may upset my inclination toward security. The current
stored procedure language is very simple.

I believe that we can find a JVM which is efficient, portable, and
open source.

>When I need to call a Java UDF on a 3 million records update, what's
>the expected performance loss I should expect compared with C? 3%, 5%,
>10%?

First, UDF's are not generally used for data update - given that they
lack client context. A Java UDF would have that context. There is
no simple answer to relative performance - Java implementations are
likely to get faster.

>Ultimately, what's the value of Java? That I can put the code in a sandbox.

That's a significant value.

>What more? Portability? Not sure. Is the JVM written in Java? Isn't C
>already ported to N+1 platforms already?

Ah, but as is well known, compiled C doesn't travel. Compiled Java does.

>Don't we have C++, Eiffel and Delphi as robust OO languages? The first two
>run on several platforms. Please help me to understand your enthusiasm for
>Java.

See above. Sand boxes and object portability.

>I'm an strong advocate of some extensions to the current sp language. I
>don't intend to throw 300 new functions in the engine's core. But there are
>some features that would make life easier:
>- BREAK and CASE.

CASE, no question. BREAK ... well there are alternatives (label & leave)
that are more elegant.

>- The ability to have a R/O context variable with the name of the table that
>invoked a trigger if some trigger is being called. Of course, if this
>trigger modifies another table and this table fires its own trigger, the
>variable has to be updated until the second trigger returns... perhaps we
>are speaking about a stack.

That one needs more thought. I suspect it's the tip of an iceberg that
has multi-table triggers under the surface.

>- The ability to have a R/O variable that gives me the number of records
>affected by my last update/delete statement. AFAIK, Oracle, SqlServer,
>Sybase and DB2 provide such facility. In IB this is only available in a
>client application (and probably in embedded SQL, not sure).

What do you get back if you update or delete from a view that's governed
by update/delete triggers?

>- Some long needed functions, like substr, length and trim.

>- Does anybody knows exactly what's all the power of Interbase?

Probably not, but we're working to gather all the bits together.

>- Does Jim know all the changes and enhancements made to the server while he
>was "retired"?

No, but he's a quick study.

>- Does anybody care to document all the hidden but legal tricks that are
>available?

Care? Sure. And maybe when the code is open, it will happen.

> Personally I believe that (and excuse me for shouting) PERHAPS
> THERE ARE
>MUCH POWER THAT NEVER WAS DOCUMENTED.

Worse, there are lots of things that were documented and no longer are.

And there are lots of things that are partially implemented and never
tested.

> how many options or system calls are in limbo
>currently?

About 70.

>How many facilities have more space for conveying data or are
>much more flexible than we know?

Nearly all of them.

>Maybe some things we want the engine to do
>are already in place and only need to be documented or polished a bit.

Some are, some aren't. Some of the ones that used to work may have been
broken in later improvements.

Ann