--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...>

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

Sure. Will probably be after Xmas, though.

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

Hmmm... I had indeed not considered this. I wonder how much it will
impact my thoughts, though. (1) Statistically, how frequent would
this occur in production? Wouldn't the effect go away after a
backup/restore? I would really appreciate hearing from anybody who
has collected stats on this. (2) Assuming that this effect is
infrequent in production, the code that fetches a field could
normalise the retrieved data to the metadata format. Wouldn't such
conversion not occur at some point anyway (ie. does this effect carry
through to the client XSQLDA struct)?

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

Unsatisfying depends on where you think the future lies. If - like
me - you think that descriptors will eventually be eliminated from
the engine, this change is helpful in ferreting out problems with
clients that will break because of it. If you think that descriptors
will stay - like yourself - it is pretty much a meaningless idea.

Perhaps the whole UDF concept needs a rethink in a scenario where
the engine supports pluggable procedural VM's. Thinking through /
prototyping an architecturally controlled runtime environment for
that is what I'm currently doing.

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

Ah, you're right -- but I wasn't talking about that. All that I meant
was that I could build a lib with a freestanding copy of the current
cvt/cvt2/mov code. This could be used to 'repair' broken UDF's when
the CVT_move export is removed. This won't get any prizes for beauty,
but it may be helpful.

Paul