I wished to know if Generic Functions or function overloading is supported in teradata UDFs written in C or not..I wished to have a function which takes input as VARCHAR or INTEGER and then have different functionality for VARCHAR and INTEGERS...I was thinking about doing it via function overloading and creating different functions for VARCHAR and INTEGER having same function name or using generic function something like <typename a> void FUNCTION_NAME ( A *arg, A* result, char sqlstate)...Is that supported in Teradata UDFs???? And if yes how to write the SQL to create these UDFs in Teradata...
Please refer to this link. I used to write C,C++ programs before but not advanced calling in TD.
With the CS option in the EXTERNAL NAME clause, the source file is transmitted from client to server, and compiled on the server. The server manages the object file that was output from the compiler. If you want to use the CS option, you will need to separate the C function definitions into two separate .c source files. The CS option is convenient and easy to use, because it does not require a compiler on the client, and does not require Linux OS login access to the Teradata Database nodes. The drawbacks are that you must separate your C functions into separate source files, and that your source code is visible to other people.
If you have compelling reason to keep the C function definitions together in the same .c source file, then you will need to take responsibility for compiling them yourself on the client side, and providing the .o object file, or the library file, to the Teradata Database. Some of those "compelling reasons" might be: If you need more control over how your C functions are organized into source files, if you need more control over the compiler settings that are used during compilation, or if you have proprietary source code that you want to protect. There is an O option for specifying a .o object file, and there is a L option for specifying a library file. Because the source code is not visible, there may be a perceived security risk, and the database administrator or security administrator may need to audit your functions before permitting them to be installed. Organizations needing this level of control also typically distribute the object files and/or library files to all the Teradata Database nodes ahead of time (which requires Linux OS login access to the Teradata Database nodes), and use the S server-side option in the EXTERNAL NAME clause.