Here is a synopsis of the steps you take to develop, compile, install, and use a UDF that does not do I/O:
- Use CREATE FUNCTION or REPLACE FUNCTION to identify the location of the source code, object, or package, and install it on a development or test database.
Recommendation: In general, you should not create UDFs in Teradata system databases such as SYSLIB or SYSUDTLIB. For more information, see Installing the Function.
The function is compiled, if the source code is submitted, linked to the dynamic linked library (DLL or SO) associated with the database in which the function resides, and distributed to all database nodes in the system.
- Test the UDF in Teradata Database in protected execution mode until you are satisfied it works correctly.
You can use the Teradata C/C++ UDF Debugger, which is a version of GDB (the gnu Source-Level Debugger) that contains extensions for Teradata Database. For more information, see C/C++ Command-line Debugging for UDFs.
Protected mode is the default execution mode for a UDF. In protected mode, Teradata Database isolates all of the data the UDF might access as a separate process in its own local workspace. This makes the function run slower. If any memory violation or other system error occurs, the error is localized to the function and the transaction executing the function.
- Use ALTER FUNCTION to change the UDF to run in nonprotected execution mode.If you subsequently use REPLACE FUNCTION to replace the function, the execution mode reverts back to protected mode.
- Rerun the tests from Step 3 to test the UDF in nonprotected execution mode until you are satisfied it works correctly.
- Install the UDF on your production database.
- Use GRANT to grant privileges to users who are authorized to use the UDF.