15.10 - function_name - Teradata Database

Teradata Database SQL Data Definition Language Syntax and Examples

Teradata Database
December 2015
Programming Reference

The calling name for the function.

This clause is mandatory for all UDFs.

A function name must conform to object naming rules. See SQL Fundamentals, B035-1141.

If you use function_name to identify the function, take care to follow the identifier naming conventions of the programming language in which it is written.

You cannot give a UDF the same name as an existing Teradata Database-supplied function (also known as an intrinsic function) unless you enclose the name in QUOTATION MARK(U+0022) characters. For example, “TRIM”(). Using the names of intrinsic functions for UDFs is a poor programming practice and should be avoided.

A UDT and a UDF without parameters that is stored in SYSUDTLIB cannot have the same name.

If the UDF library for your database contains any objects with multibyte characters in their name, you cannot use a single-byte session character set to create a new UDF, UDT, method, or Java stored procedure object even if the new object name contains only single-byte characters. Otherwise, an error is returned to the requestor. Instead, use a multibyte session character set.

function_name must match the spelling and case of the C, C++, or Java function name exactly if you do not specify a specific_function_name or external_function_name. This rule applies only to the definition of the function, not to calling it.

With the exception of row-level security policy UDFs and XML domain-specific functions with an input parameter that specifies the TD_VALIST data type, SQL supports function name overloading within the same function class, so function_name need not be unique within its class. However, you cannot give the same name to both a scalar and an aggregate function within the same database or user.

Row-level security enforcement UDFs do not support function name overloading. Because of the parameter types required by Teradata Database for input to the UDF, the same number of parameters and the same data types for the parameters are required for each UDF that executes the security policy for a specific statement action. The only difference that can exist between the parameters for UDFs that execute a security policy is that the parameters of different UDFs can either include or omit null indicators, depending on whether the constraint allows nulls.

Parameter data types and number of parameters are used to distinguish among different functions within the same class that have the same function_name.

For further information about function overloading, see SQL External Routine Programming, B035-1147.

An optional database or user name specified if the function is to be created or replaced in a non-default database or user.
If you use the recommended SYSLIB database as your UDF depository, you must modify the size of its permanent space and grant appropriate privileges on it because it is created with 0 permanent space and without access privileges.
All row-level security policy functions must reside in the SYSLIB database.
An external UDF used as a cast, ordering, or transform routine for a UDT must be created in the SYSUDTLIB database.
If you do not specify a database name, then the system creates or replaces the function within the current database.