Dalton,

> Also, IBPerl, java, Delphi, FPK, C, all the rest, require a complete
> program to operate, with SP code, you are only adding a small (probly
> under 10 lines) piece of code that is easy for a end user to understand
> and /or manipulate.

<SNIP>

> I would prefer to keep the current SP language as it is simple,
> straightforward and easy to maintain. It would be far less work to add
> one or two things to it then to try to totally rewrite the calling
> mechanism so a plugin system would work. You also have to consider
> legacy code, switching to (insert language of choice) as the embedded
> language would make the switchover very difficult for those who do not
> know (language of choice).
> Since SP code is a very simple extension to SQL code, and this is a SQL
> database, it makes sense to keep it the way it is.

I believe that's not quite the point. From what I have understood, the
general idea is to allow UDFs (and, possibly, stored procedures) to be
written in (insert language of choice); procedure language as it is
should not be touched by this feature, although I can see that some work
would have to be done to make the two approaches compatible and
transparent to the developer; I also believe that the current procedure
language needs some of the improvements of which we are speaking, _in
addition_ to the (java?) UDFs & SPs.
Please, list, let me know if I have not understood properly.
Regards
--
____
_/\/ando