paulruizendaal wrote:

>I think you misunderstand me. I do not propose to store the state of
>the VM (virtual CPU, virtual stack, etc.) on the C/C++ stack. I don't
>see the advantage of that (and you mention some important drawbacks
>too).
>
>What I have in mind is a more a change of presentation than a change
>of actual logic:
>request -> virtual process
>JRD_NOD tree(s) -> virtual code sections
>impure area(s) -> virtual stack/heap
>looper -> virtual CPU
>etc.
>

I'm sorry, I don't have any idea of what you're talking about. Could
you explain it greater length?

>Two points here.
>(2) Not compiling is certainly better. This is why we have
>prepare/execute. I agree that many contemporary client RAD tools
>don't promote doing things the prepare/execute way, but just do
>exec_immed's. Here server side chacing would be a benefit. How would
>this work? (All I can think of now is to check for identical SQL
>strings vs. recent history for the same client attachment).
>
>

A compiled statement cache entered by exact SQL string. A miss is
compiled and entered into the cache. Anybody who embeds data in
generated SQL strings loses. It hit must be validated for security.
If/when Firebird grows name spaces and filtersets, SQL statements must
handled as potentially overloaded.

>>Pish-tosh. Since records can be of different format, you don't
>>
>>
>know the datatype until runtime.
>
>
>
>Hmmm... I don't get this. Sounds like I missed something crucially
>important. Could you please elaborate, if you have time. Anybody else
>can jump in too, to explain.
>
>

Sure. Somebody declares a field as a short, changes his mind and make
it a long. The datameta says long. The compiler can wish/hope that
when the data is fetched it will be a long, but sometimes it's going to
be short. Or a string or whatever, The compiler can legitmate decide,
based on metadata, that comparisons are to be performed with numeric
semantics, forcing a string to a number, but it can't force the middle
reaches of the engine to produce data of any type but what exists on
disk in a record of a specific format.

>I appologise for being abrasive; I got carried away a bit. Didn't
>know it was you who added UDF's by descriptor, but anybody would have
>deserved more civility.
>
>

OK, lets have a mutual moritorium on declarations of brain death. That
will let us concentrate on the argument we trying to make.

>>Gosh, a new value struct sounds remarkably like a descriptor.
>>
>>
>Could you
>
>
>>kindly explain the difference to those of us who are brain dead?
>>
>>
>
>The difference is that the new struct would not contain type
>information.
>
>

You know, Paul, that's a very unsatisfying answer. It is a descriptor
and an incomplete one at that.

>
>
>>>Slightly off-topic, I do see the need to provide UDF users with a
>>>tool to cast types, especially from date to string and vice versa.
>>>Would it be an idea to kill the current CVT_move entry point and to
>>>bundle a separate dynamic lib with a type conversion utility like
>>>CVT_move. I was thinking of doing something like that anyway.
>>>
>>>
>>>
>>Hard problem, no existence proof of a solution. Good luck.
>>
>>
>
>Again, I don't understand this, but I take it as a "no, thank you, we
>see no use for such a thing"
>
>
>

No, not at all. I meant it that exporting an meaningful architecturally
controlled runtime environment for UDF is a hard problem. I did the
tiniest subset of one for blobs and decided I didn't really want to go
there.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376