Archives of the TeradataForum

Message Posted: Mon, 17 Dec 2007 @ 08:58:36 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Thanks David, I'm all embarrassed now. But your closing statement covers it nicely:

On the subject of other languages:

I believe that there is a rumour that a future not to distant version of Teradata will allow Java functions. I don't know if that is for all types of functions or a subset of types (i.e. UDF, UDT, Table function, XSP etc).

I think that the same dearth of programmers would apply for the same reasons as it does for 'c' programmers (lack of continuous need and understanding of set operations).

Theoretically if a language can be called from 'C' (e.g. VBA) you could call other "foreign" languages from your function - but I'm thinking that that would be terribly inefficient.

Specifically, do you really want to load 700GB of VBA run time DLL's every time Teradata needs to call your foreign language function - presumably for each row processed? I really don't know how big a VBA runtime environment is, but you get the idea.

Not to mention you would still need the 'C' function to call your "foreign language" routine in the first place. And you can't really get away with a generic 'c' function (unless you are a pointer super-wizard - very advanced users only).

Which raises the question as to how they will deal with these issues if Java becomes an option? In particular the run time environment question! This typically isn't a problem for 'c' routines - which is presumably why 'c' was the first to be supported.

BTW. Did you want the bridge to go with that?

	<Prev	Next>		<<First	<Prev	Next>	Last>>