External String Literal - Advanced SQL Engine - Teradata Database

SQL Data Definition Language Detailed Topics

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
imq1591724555718.ditamap
dita:ditavalPath
imq1591724555718.ditaval
dita:id
B035-1184
lifecycle
previous
Product Category
Teradata Vantage™

The external string literal specifies an encoded list of the components required to create a UDF. When decoded, the string specifies what each component is and where it is located.

Depending on the requirements of the specific UDF, you can specify the following components:

The system uses the code path to access the file it specifies, then adds an appropriate extension as it transfers that file to the UDF compile directory on the platform.

Do not use the following characters as the delimiter because they might be interpreted as a component of a path string rather than as a delimiter:
  • / (SOLIDUS)
  • \ (REVERSE SOLIDUS)
  • : (COLON)

You must use the same delimiter character throughout the specified path string.

Vantage retrieves the source component from the specified client or server when it requests the source or object code. The system saves the function entry point name component in the dictionary and then uses that name to invoke the function.

You should name any include files (C/C++ header files) with the same name as specified in the C/C++ include directive of the C or C++ source file (see Teradata Vantage™ - SQL External Routine Programming, B035-1147).

For example for a z/OS client:

'CI¡sqltypes_td¡UDFDEFS¡CS¡myudf¡UDFSRC¡F¡theudf'

where UDFDEFS and UDFSRC are the DDNAMEs for the files on the z/OS client system. Whenever you refer to an IBM client file in a code path, you must identify it by its client DDNAME.

This clause causes the system to do the following things:
  • Retrieve the file UDFDEFS and rename it to udfdefs.h in the UDF compile directory for the platform.
  • Retrieve UDFSRC and rename it to myudf.c in the UDF compile directory for the platform.

The C or C++ source myudf.c should contain the following code:

#include <udfdefs.h>

or

#include "udfdefs.h"

The clause also specifies the F option, which stipulates that the function entry name is theudf. The C or C++ file named theudf must then have the following skeletal code:

void the udf ( ... )
 {
  ...
 }

You cannot specify the F option unless you also specify a source, object, package, or library file in the specification string.

Suppose you specify the following skeletal CREATE FUNCTION statement, where the omitted details are denoted by an ELLIPSIS (...) character:

CREATE FUNCTION abc(...)
 ...
EXTERNAL NAME 'CS!matrix!matrix.c';

The name of the C or C++ source file in this example is matrix.c and the C or C++ function name, based on the function name abc, must have the following skeletal code:

void abc(...)
 {
  ...
 }

Suppose you specify the following skeletal CREATE FUNCTION statement, where, again, the omitted details are denoted by an ellipsis (...):

CREATE FUNCTION abc(...)
 ...
EXTERNAL NAME 'CO!matrix!matrix.o';

There is no source file for this function; instead, the code is an object file named matrix.o.

For this CREATE FUNCTION statement to compile successfully, there must be a function in the specified object file named abc.

See the table at the end of the External String Literal Examples topic for more information about function name usage.

You can specify the various options as many times as needed except for the package option, which cannot be used in combination with any of the other options except the C/C++ function entry point name option.