Sentencia CREATE FUNCTION (tabla externa)

La sentencia CREATE FUNCTION (Tabla externa) se utiliza para registrar una función de tabla externa definida por el usuario en el servidor actual.

En la cláusula FROM de una sentencia SELECT, puede utilizarse una función de tabla y esta devuelve una tabla a la sentencia SELECT de fila en fila.

Invocación

Esta sentencia se puede incorporar a un programa de aplicación o emitir mediante el uso de sentencias de SQL dinámico. Es una sentencia ejecutable que puede prepararse de forma dinámica sólo si el comportamiento de ejecución de DYNAMICRULES está en vigor para el paquete (SQLSTATE 42509).

Autorización

Los privilegios que posee el ID de autorización de la sentencia debe tener al menos una de las autorizaciones siguientes:

Autorización CREATE_EXTERNAL_ROUTINE para la base de datos y, como mínimo, una de las autorizaciones siguientes:
- Autorización IMPLICIT_SCHEMA en la base de datos, si el nombre de esquema implícito o explícito de la función no existe
- El privilegio CREATEIN para el esquema, si existe el nombre de esquema de la función
- Autoridad SCHEMAADM en el esquema, si existe el nombre de esquema de la función
Autorización DBADM

Los privilegios de grupo para cualquier tabla o vista especificada en la sentencia CREATE FUNCTION no se tienen en cuenta.

Para crear una función no delimitada, los privilegios del ID de autorización de la sentencia debe incluir, como mínimo, una de las autorizaciones siguientes:

Autorización CREATE_NOT_FENCED_ROUTINE para la base de datos
Autorización DBADM

Para crear una función delimitada, no se necesitan autorizaciones ni privilegios adicionales.

Para sustituir una función existente, el ID de autorización de la sentencia debe ser el propietario de la función existente (SQLSTATE 42501).

Si se especifica la opción SECURED, el ID de autorización de la sentencia debe incluir la autorización SECADM o CREATE_SECURE_OBJECT (SQLSTATE 42501).

Sintaxis

declaración-parámetro

tipo1-datos, tipo2-datos

tipo-incorporado

cláusula-por-omisión

lista-opciones

Notas:

¹ La cláusula FOR BIT DATA se puede especificar en cualquier orden con las restricciones de columna siguientes. La cláusula FOR BIT DATA no se puede especificar con unidades de serie CODEUNITS32 (SQLSTATE 42613).
² DB2SECURITYLABEL es el tipo diferenciado incorporado que debe utilizarse para definir la columna de etiqueta de seguridad de fila de una tabla protegida.
³ Para una columna de tipo DB2SECURITYLABEL, NOT NULL WITH DEFAULT está implícito y no se puede especificar explícitamente (SQLSTATE 42842). El valor por omisión de una columna de tipo DB2SECURITYLABEL es la etiqueta de seguridad del ID de autorización de sesión correspondiente al acceso de grabación.
⁴ Para obtener información acerca de la creación de funciones de tabla externa LANGUAGE OLE DB, consulte CREATE FUNCTION (Tabla externa OLE DB). Para obtener información sobre cómo crear funciones de tabla LANGUAGE SQL, consulte CREATE FUNCTION (escalar de SQL, tabla o fila).

Descripción

OR REPLACE

Especifica que se debe sustituir la definición de la función si existe una en el servidor actual. La definición existente se descarta de forma efectiva antes de que la nueva definición se sustituya en el catálogo, con la excepción de que los privilegios que se han otorgado sobre la función no se ven afectados por ello. Esta opción sólo puede especificarla el propietario del objeto. Esta opción se ignora si no existe una definición para la función en el servidor actual. Para sustituir una función ya existente, el nombre específico y el nombre de función de la nueva definición tienen que ser los mismos que el nombre específico y el nombre de función de la antigua definición, o la signatura de la nueva definición debe coincidir con la signatura de la antigua definición. De lo contrario, se creará una nueva función.

Si se hace referencia a la función en la definición de un permiso de fila o una máscara de columna, la función no se puede sustituir (SQLSTATE 42893).

nombre-función

Indica el nombre de la función que se está definiendo. Consiste en el nombre, calificado o no calificado, que designa una función. El formato no calificado de un nombre-función es un identificador SQL. En las sentencias de SQL dinámico, el registro especial CURRENT SCHEMA se utiliza como calificador para un nombre de objeto no calificado. En sentencias de SQL estático, la opción de precompilación/vinculación QUALIFIER especifica de forma implícita el calificador para los nombres de objeto no calificados. La forma calificada es un nombre-esquema seguido de un punto y un identificador de SQL. El nombre calificado no debe ser el mismo que el tipo de datos del primer parámetro, si ese parámetro es un tipo estructurado.

El nombre, incluidos los calificadores implícitos y explícitos, junto con el número de parámetros y el tipo de datos de cada parámetro (sin tener en cuenta ningún atributo de longitud, precisión o escala del tipo de datos) no debe identificar una función descrita en el catálogo (SQLSTATE 42723). El nombre no calificado, junto con el número y el tipo de datos de los parámetros, que por supuesto es exclusivo en su esquema, no es necesario que lo sea en todos los esquemas.

Si se especifica un nombre de dos partes, el nombre-esquema no puede empezar por SYS (SQLSTATE 42939).

Algunos nombres que se utilizan como palabras clave en los predicados están reservados para que los utilice el sistema y no pueden utilizarse como nombre-función (SQLSTATE 42939). Los nombres son SOME, ANY, ALL, NOT, AND, OR, BETWEEN, NULL, LIKE, EXISTS, IN, UNIQUE, OVERLAPS, SIMILAR, MATCH y los operadores de comparación.

Se puede utilizar el mismo nombre para más de una función si hay alguna diferencia en la signatura de las funciones. Aunque no hay ninguna prohibición al respecto, una función de tabla externa definida por el usuario no debe tener el mismo nombre que una función incorporada.

(declaración-parámetro,...)

Identifica el número de parámetros de entrada de la función y especifica el tipo de datos y el valor por omisión opcional de cada parámetro. En la lista debe especificarse una entrada por cada parámetro que la función espera recibir. No se permiten más de 90 parámetros (SQLSTATE 54023).

Existe la posibilidad de registrar una función que no tenga ningún parámetro. En este caso, sigue siendo necesaria la codificación de los paréntesis, sin incluir ningún tipo de datos. Por ejemplo:

   CREATE FUNCTION WOOFER() ...

En un esquema, no se permite que dos funciones que se denominen igual tengan exactamente el mismo tipo para todos los parámetros correspondientes. Las longitudes, precisiones y escalas no se consideran en esta comparación de tipos. Por esta razón, se considera que CHAR(8) y CHAR(35) tienen el mismo tipo, al igual que DECIMAL(11,2) y DECIMAL (4,3). Se considera que la especificación de un tipo diferenciado con tipo no firme es del mismo tipo de datos que el tipo de fuente del tipo diferenciado. Para una base de datos Unicode, se considera que CHAR(13) y GRAPHIC(8) son del mismo tipo. Hay una agrupación más profunda de los tipos que hace que se traten como el mismo tipo para esta finalidad como, por ejemplo, DECIMAL y NUMERIC. Una signatura duplicada devuelve un error (SQLSTATE 42723).

nombre-parámetro

Especifica un nombre opcional para el parámetro de entrada. El nombre no puede ser el mismo que el de cualquier otro nombre-parámetro de la lista de parámetros (SQLSTATE 42734).

tipo1-datos

Especifica el tipo de datos del parámetro de entrada. El tipo de datos puede ser un tipo de datos incorporado, un tipo diferenciado, un tipo estructurado o un tipo de referencia. Para obtener una descripción más completa de cada tipo de datos incorporado, consulte CREATE TABLE. Algunos tipos de datos no se soportan en todos los idiomas. Para obtener detalles sobre la correlación entre tipos de datos SQL y tipos de datos de lenguaje principal, consulte Tipos de datos que se correlacionan con tipos de datos de SQL en aplicaciones SQL incorporadas.

Un parámetro de tipo fecha y hora se pasa como tipo de datos de tipo carácter y los datos se pasan en formato ISO.
DECIMAL (y NUMERIC) no son válidos con LANGUAGE C y OLE (SQLSTATE 42815).
XML no es válido con LANGUAGE OLE.
Dado que el valor XML que se ve dentro de una función es una versión serializada del valor XML que se pasa como parámetro en la llamada de función, los parámetros del tipo XML deben declararse mediante la sintaxis XML AS CLOB(n).
CLR no da soporte a una escala DECIMAL mayor que 28 (SQLSTATE 42613).
No se pueden especificar tipos array (SQLSTATE 42815).
Los tipos de datos BINARY y VARBINARY no son válidos con LANGUAGE CLR y OLE (SQLSTATE 42815).

Para un tipo diferenciado definido por el usuario, los atributos de longitud, precisión o escala para el parámetro son los del tipo fuente del tipo diferenciado (los especificados en CREATE TYPE). Un parámetro de tipo diferenciado se pasa como tipo fuente del tipo diferenciado. Si el nombre del tipo diferenciado no está calificado, el gestor de base de datos resuelve el nombre de esquema buscando los esquemas en la vía de acceso de SQL.

Para un tipo estructurado definido por el usuario, deben existir las funciones de transformación apropiadas en el grupo de transformación asociado.

Para un tipo de referencia, el parámetro se puede especificar como REF(nombre-tipo) si el parámetro no tiene ámbito.

DEFAULT

Especifica un valor por omisión para el parámetro. El valor por omisión puede ser una constante, un registro especial, una variable global, una expresión o la palabra clave NULL. Los registros especiales que se pueden especificar como el valor por omisión son los mismos que se pueden especificar para un valor por omisión de columna (véase cláusula-por-omisión en la sentencia CREATE TABLE). Se pueden especificar otros registros especiales como valor por omisión utilizando una expresión.

La expresión puede ser cualquier expresión del tipo que se describe en el apartado Expresiones. Si no se especifica un valor por omisión, el parámetro no tendrá ningún valor por omisión y no se podrá omitir el argumento correspondiente al invocar el procedimiento. El tamaño máximo de la expresión es de 64 K bytes.

La expresión por omisión no debe modificar datos SQL (SQLSTATE 428FL o SQLSTATE 429BL). La expresión debe ser compatible con asignaciones con el tipo de datos del parámetro (SQLSTATE 42821).

No se puede especificar un valor por omisión para un parámetro del tipo ARRAY, ROW o CURSOR (SQLSTATE 429BB).

AS LOCATOR

Especifica que se pasa un localizador para el valor del parámetro a la función en lugar del valor real. Especifique AS LOCATOR sólo para parámetros con un tipo de datos LOB o un tipo diferenciado basado en un tipo de datos LOB (SQLSTATE 42601). El hecho de pasar localizadores en lugar de valores puede hacer que se pasen menos bytes a la función, especialmente cuando el valor del parámetro es muy grande.

La cláusula AS LOCATOR no tiene ningún efecto para determinar si los tipos de datos se pueden promocionar, ni afecta a la signatura de función, que se utiliza en la resolución de función.

Si la función es FENCED y tiene la opción NO SQL, no puede especificarse la cláusula AS LOCATOR (SQLSTATE 42613).

RETURNS

Especifica la salida de la función.

TABLE

Especifica que el resultado de la función es una tabla. El paréntesis que sigue a esta palabra clave delimita una lista de nombres y tipos de las columnas de la tabla. El estilo de lista es parecido al estilo de una sentencia CREATE TABLE simple que no tenga especificaciones adicionales (restricciones, por ejemplo). No están permitidas más de 255 columnas (SQLSTATE 54011).

nombre-columna

Especifica el nombre de esta columna. El nombre no puede estar calificado y no se puede utilizar el mismo nombre para más de una columna de la tabla.

tipo2-datos

Especifica el tipo de datos de la columna y puede ser cualquier tipo de datos soportado para un parámetro de una UDF escrita en el lenguaje determinado, excepto para tipos estructurados (SQLSTATE 42997).

AS LOCATOR: Cuando tipo-datos2 es un tipo LOB o un tipo diferenciado basado en un tipo LOB, la utilización de esta opción indica que la función devuelve un localizador para el valor LOB que tiene su instancia en la tabla de resultados.
Los tipos válidos que se pueden utilizar con esta cláusula se describen en el tema de la sentencia CREATE FUNCTION (escalar externa).

GENERIC TABLE

Especifica que la salida de la función es una tabla genérica. Esta cláusula sólo está permitida si se especifica la cláusula LANGUAGE JAVA y la cláusula PARAMETER STYLE DB2GENERAL (SQLSTATE 42613).

tipo-incorporado

Consulte en CREATE TABLE la descripción de los tipos de datos incorporados.

SPECIFIC nombre-específico

Proporciona un nombre exclusivo para la instancia de la función que se está definiendo. Este nombre específico puede utilizarse cuando se utiliza esta función como fuente, al descartar la función o bien al comentarla. Nunca puede emplearse para invocar a la función. El formato no calificado de un nombre-específico es un identificador SQL. La forma calificada es un nombre-esquema seguido de un punto y un identificador de SQL. El nombre (incluido el calificador implícito o explícito) no debe identificar a otra instancia de la función que ya exista en el servidor de aplicaciones; de lo contrario, se genera un error. (SQLSTATE 42710).

El nombre-específico puede ser el mismo que un nombre-función ya existente.

Si no se especifica ningún calificador, se emplea el que se haya utilizado para el nombre-función. Si se especifica un calificador, éste debe ser el mismo que el calificador explícito o implícito del nombre-función; de lo contrario se produce un error (SQLSTATE 42882).

Si no se especifica el nombre-específico, el gestor de bases de datos genera un nombre exclusivo. El nombre exclusivo es SQL seguido de una indicación de fecha y hora en forma de serie caracteres: SQLaammddhhmmssxxx.

EXTERNAL

Esta cláusula indica que la sentencia CREATE FUNCTION se emplea para registrar una nueva función basada en el código escrito en un lenguaje de programación externo y cumple los convenios estipulados para los enlaces e interfaces.

Si no se especifica la cláusula NAME, se da por supuesto NAME nombre-función.

NAME 'serie'

Esta cláusula identifica el código escrito por el usuario que implanta la función que se está definiendo.

La opción 'serie' es una constante de tipo serie con un máximo de 254 bytes. El formato que se utiliza para la serie depende de la opción LANGUAGE especificada.

Para LANGUAGE C:

La serie especificada constituye el nombre de la biblioteca y la función de la biblioteca, que el gestor de bases de datos invoca para ejecutar la función definida por el usuario que se está creando. Al ejecutar la sentencia CREATE FUNCTION, no es preciso que exista la biblioteca (ni la función de dentro de la biblioteca). No obstante, cuando se emplea esta función en una sentencia de SQL, la biblioteca y la función de la biblioteca sí deben existir y estar accesibles desde la máquina que actúa como servidor de bases de datos.

La serie se puede especificar de la forma siguiente:

Dentro de las comillas simples no está permitido especificar espacios en blanco adicionales.

id-biblioteca

Identifica el nombre de la biblioteca que contiene la función. El gestor de bases de datos buscará en la biblioteca de la manera siguiente:

Sistema operativo	Ubicación de nombre de biblioteca
Linux AIX Solaris HP-UX	Si `myfunc` se ha proporcionado como id_biblioteca y el gestor de bases de datos se está ejecutando desde /u/production, el gestor de bases de datos buscará la función en la biblioteca /u/production/sqllib/function/myfunc
Windows	El gestor de bases de datos buscará la función en la vía de acceso de directorio especificada por la variable de entorno LIBPATH o PATH

id-vía-acceso-absoluta

Identifica el nombre completo de vía de acceso del archivo que contiene la función. El formato depende del sistema operativo, como se ilustra en la tabla siguiente:

Sistema operativo	Ejemplo de nombre completo de vía de acceso
Linux AIX Solaris HP-UX	Un valor de '/u/jchui/mylib/myfunc' hará que el gestor de bases de datos busque en /u/jchui/mylib la biblioteca compartida myfunc.
Windows	Un valor de 'd:\mylib\myfunc.dll' hará que el gestor de bases de datos cargue la biblioteca de enlaces dinámicos, myfunc.dll, del directorio d:\mylib. Si se utiliza un ID de vía de acceso absoluta para identificar el cuerpo de la rutina, asegúrese de añadir la extensión .dll.

! id-función

Identifica el nombre del punto de entrada de la función que debe invocarse. El ! sirve como delimitador entre el ID de biblioteca y el ID de función. El formato depende del sistema operativo, como se ilustra en la tabla siguiente:

Sistema operativo	Nombre del punto de entrada de la función
Linux AIX Solaris HP-UX	Un valor de 'mymod!func8' indicará al gestor de bases de datos que busque la biblioteca $inst_home_dir/sqllib/function/mymod y utilice el punto de entrada func8 en esa biblioteca.
Windows	Un valor de 'mymod!func8' indicará al gestor de bases de datos que cargue el archivo mymod.dll y llame a la función func8() en la biblioteca de enlaces dinámicos (DLL).

Si la serie no se ha formado correctamente, se devuelve un error (SQLSTATE 42878).

En cualquier caso, el cuerpo de cada función externa debe estar en un directorio que sea accesible en todas las particiones de base de datos.

Para LANGUAGE JAVA:
La serie especificada contiene el identificador opcional del archivo jar, el identificador de clase y el identificador de método, que el gestor de bases de datos invoca para ejecutar la función definida por el usuario que se está creando. No es necesario que existan el identificador de clase ni el identificador de método cuando se ejecuta la sentencia CREATE FUNCTION. Si se especifica un id_jar, éste deberá existir cuando se ejecute la sentencia CREATE FUNCTION. No obstante, cuando se utiliza la función en una sentencia de SQL, debe existir el identificador de método y debe ser accesible desde la máquina servidora de bases de datos.

La serie se puede especificar de la forma siguiente:

Dentro de las comillas simples no está permitido especificar espacios en blanco adicionales.

id-jar

Designa el identificador de jar que se asignó a la colección jar cuando se instaló en la base de datos. Puede ser un identificador simple o un identificador calificado por un esquema. Algunos ejemplos son 'miJar' y 'miEsquema.miJar'

id-clase

Identifica el identificador de clase del objeto Java™. Si la clase forma parte de un paquete, la parte del identificador de clase debe incluir el prefijo completo del paquete, por ejemplo 'myPacks.UserFuncs'. El directorio en el que la máquina virtual Java buscará las clases depende del sistema operativo, como se ilustra en la tabla siguiente:

Sistema operativo Directorio en el que la máquina virtual Java buscará las clases

Linux

AIX
Solaris
HP-UX

'.../myPacks/UserFuncs/'

Windows '...\myPacks\UserFuncs\'

id-método

Identifica el nombre del método del objeto Java que se invocará.
Para LANGUAGE CLR:
La serie especificada representa el ensamblaje .NET (biblioteca o ejecutable), la clase de ese ensamblaje y el método de la clase que el gestor de bases de datos invoca para ejecutar la función que se crea. No es necesario que existan el módulo, la clase y el método cuando se ejecuta la sentencia CREATE FUNCTION. No obstante, cuando se utiliza la función en una sentencia de SQL, el módulo, la clase y el método deben existir y se deben poder acceder desde la máquina del servidor de bases de datos; de lo contrario, se devolverá un error (SQLSTATE 42724).

Las rutinas C++ que se compilan con la opción de compilador '/clr' para indicar que incluyen extensiones de código gestionado deben estar catalogadas como 'LANGUAGE CLR' y no como 'LANGUAGE C'. El servidor de base de datos debe conocer que se está utilizando la infraestructura .NET en una función definida por el usuario para tomar decisiones necesarias en tiempo de ejecución. Todas las funciones definidas por el usuario utilizando la infraestructura .NET deben estar catalogadas como 'LANGUAGE CLR'.

La serie se puede especificar de la forma siguiente:

El nombre debe especificarse entre comillas simples. No está permitido especificar espacios en blanco adicionales.

ensamblaje

Identifica el DLL u otro archivo de ensamblaje en el que reside la clase. Se debe especifica alguna extensión de archivo (como .dll). Si no se proporciona el nombre de vía de acceso completo, el archivo debe residir en el dirección de función de la vía de acceso de instalación del producto de base de datos.
Por ejemplo c:\sqllib\function.

Si el archivo reside en un subdirectorio del directorio function de la instalación, se puede especificar el subdirectorio antes del nombre de archivo en lugar de especificar toda la vía de acceso.

Por ejemplo, si el directorio de instalación es c:\sqllib y el archivo de ensamblaje es c:\sqllib\function\myprocs\mydotnet.dll, sólo es necesario especificar 'myprocs\mydotnet.dll' para el ensamblaje.

La sensibilidad a las mayúsculas y minúsculas de este parámetro es igual a la del sistema de archivos.

id-clase

Especifica el nombre de la clase del ensamblaje proporcionado en el que reside el método que se debe invocar. Si la clase reside en un espacio de nombres, se debe facilitar el espacio de nombres completo además de la clase. Por ejemplo, si la clase EmployeeClass está en el espacio de nombres MyCompany.ProcedureClasses, se debe especificar MyCompany.ProcedureClasses.EmployeeClass para la clase. Tenga en cuenta que los compiladores para algunos lenguajes .NET añadirán el nombre del proyecto como espacio de nombres para la clase y el comportamiento puede diferir según se utilice el compilador de la línea de mandatos o el compilador de la GUI. Este parámetro es sensible a las mayúsculas y minúsculas.

id-método

Especifica el método de la clase que se debe invocar. Este parámetro es sensible a las mayúsculas y minúsculas.
Para LANGUAGE OLE:
La serie especificada es el identificador de programa OLE (idprog) o identificador de clase (clsid) y el identificador del método, que invoca el gestor de bases de datos para ejecutar la función definida por el usuario que se está creando. No es preciso que exista el identificador de programa ni el identificador de clase y el identificador de método al ejecutar la sentencia CREATE FUNCTION. No obstante, cuando la función se utiliza en una sentencia de SQL, el identificador de método debe existir y debe poder accederse a éste desde la máquina del servidor de bases de datos; de lo contrario, se devuelve un error (SQLSTATE 42724).

La serie se puede especificar de la forma siguiente:

Dentro de las comillas simples no está permitido especificar espacios en blanco adicionales.

idprog

Identifica el identificador de programa del objeto OLE.
idprog no se interpreta por el gestor de bases de datos sino que sólo se reenvía a la API OLE en tiempo de ejecución. El objeto OLE especificado debe poderse crear y dar soporte a un enlace lógico posterior (denominado también enlace lógico basado en IDispatch).

idcls

Designa el identificador de clase del objeto OLE que se debe crear. Puede utilizarse como una alternativa para especificar idprog en el caso de que el objeto OLE no esté registrado con un idprog. El idcls tiene el formato:
{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}

donde 'n' es un carácter alfanumérico. idcls no se interpreta por el gestor de bases de datos, sólo se reenvía a las API OLE en el momento de la ejecución.

id-método

Identifica el nombre del método del objeto OLE que se debe invocar.
Para LANGUAGE CPP:
La serie especificada es el identificador de bibliorteca y el identificador de clase dentro de la biblioteca, que contiene el método de evaluación que el gestor de bases de datos invoca para ejecutar la función definida por el usuario que se está creando. Si la serie no se ha formado correctamente, se devuelve un error (SQLSTATE 42878).

Al ejecutar la sentencia CREATE FUNCTION, no es preciso que exista la biblioteca (ni la clase de dentro de la biblioteca). No obstante, cuando la función se utiliza en una sentencia SQL, la biblioteca y la clase que está dentro de la biblioteca deben existir y debe poder accederse a éstas desde la máquina del servidor de bases de datos; de lo contrario, se devuelve un error (SQLSTATE 42724).

El cuerpo de cada función externa debe estar en un directorio que sea accesible en todas las particiones de base de datos.
La serie se puede especificar de la forma siguiente:
Dentro de las comillas simples no está permitido especificar espacios en blanco adicionales.
id-biblioteca
Nombre de la biblioteca que contiene la función:
- En un sistema UNIX, si el ID de biblioteca especificado es myfunc, y si el gestor de bases de datos se está ejecutando desde /u/production, el gestor de bases de datos buscará la función en la biblioteca siguiente:
  /u/production/sqllib/function/myfunc
- En un sistema operativo Windows, el gestor de bases de datos buscará la función en la vía de acceso del directorio que las variables de entorno LIBPATH o PATH especifican.
id-vía-acceso-absoluta
La vía de acceso completa del archivo que contiene la función. Por ejemplo:
- En un sistema UNIX, la siguiente especificación hará que el gestor de bases de datos busque en /u/jchui/mylib la biblioteca compartida myfunc:
  '/u/jchui/mylib/myfunc'
- En un sistema operativo Windows, la siguiente especificación hace que el gestor de bases de datos cargue la biblioteca de enlace dinámico myfunc.dll desde el directorio d:\mylib:
  'd:\mylib\myfunc.dll'
  Si se utiliza un ID de vía de acceso absoluta para identificar el cuerpo de la rutina, asegúrese de añadir la extensión .dll.
id-clase

Nombre de la clase que contiene los métodos que se están invocando.
Por ejemplo, si especifica 'mymod!myclass':
- En un sistema UNIX, el gestor de bases de datos buscar la biblioteca $inst_home_dir/sqllib/function/mymod e invoca el método evaluate de la clase myclass en esa biblioteca.
- En un sistema operativo Windows, el gestor de bases de datos carga el archivo mymod.dll y llama al método evaluate de la clase myclass en la biblioteca de enlace dinámico (DLL).

NAME identificador

Sistema operativo	Directorio en el que la máquina virtual Java buscará las clases
Linux AIX Solaris HP-UX	'.../myPacks/UserFuncs/'
Windows	'...\myPacks\UserFuncs\'

Esta cláusula identifica el nombre del código escrito por el usuario que implanta la función que se está definiendo. El identificador especificado es un identificador de SQL. El identificador SQL se utiliza como el id-biblioteca en la serie. A menos que sea un identificador delimitado, se convierte a mayúsculas. Si el identificador está calificado con un nombre de esquema, se ignora la parte correspondiente al nombre del esquema. Este formato de NAME sólo puede utilizarse con LANGUAGE C.

LANGUAGE

Esta cláusula obligatoria se emplea para especificar el convenio de la interfaz de lenguaje para la que está escrito el cuerpo de la función definida por el usuario.

C: Esto significa que el gestor de bases de datos llamará a la función definida por el usuario como si se tratase de una función en C. La función definida por el usuario debe ajustarse al convenio de llamadas y enlaces del lenguaje C, tal y como se define en el prototipo de C estándar de ANSI.
JAVA: Esto significa que el gestor de bases de datos llamará a la función definida por el usuario como un método de una clase Java.
CLR: Reservado para una utilización futura.
OLE: Reservado para una utilización futura.
CPP: El gestor de bases de datos llama a la función definida por el usuario invocando el método evaluate de una clase C++.

PARAMETER STYLE

Esta cláusula se utiliza para especificar los convenios utilizados para pasar parámetros a funciones y devolver el valor de las mismas.

DB2GENERAL

Se utiliza para especificar los convenios para pasar parámetros a funciones externas y para devolver los valores procedentes de esas funciones, que están definidas como método en una clase Java. Esto sólo puede especificarse cuando se utiliza LANGUAGE JAVA.

SQL

Se utiliza para especificar los convenios para pasar parámetros y para devolver el valor de funciones externas que cumplen con los convenios de llamada y enlace del lenguaje C, los métodos expuestos por los objetos de automatización OLE o los métodos estáticos públicos de un objeto .NET. Se debe especificar cuando se utiliza LANGUAGE C, LANGUAGE CLR o LANGUAGE OLE.

NPSGENERIC

Se utiliza para especificar los convenios para pasar parámetros a funciones externas y para devolver el valor procedente de esas funciones, que están definidas como método en una clase C++. Esto se pueden especificar únicamente cuando se establece la opción LANGUAGE en CPP.

Cuando se especifica NPSGENERIC como estilo de parámetro, la UDF se escribe en C++ como una clase derivada de la clase nz.udx_ver2.Udf. La clase debe implementar los dos métodos siguientes junto con su constructor y destructor:

static Udf* Udf::instantiate(UdxInit *pInit): Método de miembro estático instantiate(), que debe crear una instancia nueva de la clase UDF derivada y devolver un puntero para la nueva instancia como un puntero de clase Udf. El motor utiliza este método para crear una instancia de un objeto UDF.
virtual ReturnValue Udf::evaluate(): Método de miembro evaluate(), al que llama el motor para evaluar la función de usuario y devolver un valor a quien realiza la llamada.

PARAMETER CCSID

Especifica el esquema de codificación que se debe utilizar para todos los datos de serie que se pasan a la función y desde ella. Si no se especifica la cláusula PARAMETER CCSID, el valor por omisión es PARAMETER CCSID UNICODE para las bases de datos Unicode y PARAMETER CCSID ASCII para todas las demás bases de datos.

ASCII

Especifica que los datos de serie están codificados en la página de códigos de la base de datos. Si la base de datos es Unicode, no se puede especificar PARAMETER CCSID ASCII (SQLSTATE 56031). Cuando se invoca la función, la página de códigos de la aplicación para la función es la página de códigos de la base de datos.

UNICODE

Especifica que los datos de serie están codificados en Unicode. Si la base de datos es Unicode, los datos de caracteres están en UTF-8 y los datos gráficos están en UCS-2. Si la base de datos no es Unicode, los datos de caracteres están en UTF-8. En cualquier caso, cuando se invoca la función, la página de códigos de la aplicación para la función es 1208.

Si la base de datos no es Unicode y se crea una función con PARAMETER CCSID UNICODE, la función no puede tener ningún tipo gráfico ni ningún tipo definido por el usuario (SQLSTATE 560C1).

Si la base de datos no es Unicode, se pueden crear funciones de tabla con PARAMETER CCSID UNICODE, pero se aplican las normas siguientes:

Se debe especificar un orden de clasificación alternativo en la configuración de la base de datos antes de crear la función de tabla (SQLSTATE 56031). Las funciones de tabla PARAMETER CCSID UNICODE se clasifican con el orden de clasificación alternativo especificado en la configuración de la base de datos.
No se pueden utilizar conjuntamente las tablas o las funciones de tablas creadas con CCSID ASCII y las tablas o las funciones de tablas creadas con CCSID UNICODE en una sola sentencia de SQL (SQLSTATE 53090). Esto se aplica a las tablas y a las funciones de tabla a las que se hace referencia directamente en la sentencia, así como a las tablas y las funciones de tabla a las que se hace referencia indirectamente (por ejemplo, mediante restricciones de integridad referencial, activadores, tablas de consulta materializada y tablas de los cuerpos de las vistas).
No se puede hacer referencia a las funciones de tabla creadas con PARAMETER CCSID UNICODE en funciones de SQL ni en métodos de SQL (SQLSTATE 560C0).
Una sentencia de SQL que hace referencia a una función de tabla creada con PARAMETER CCSID UNICODE no puede invocar una función de SQL ni un método de SQL (SQLSTATE 53090).
Los tipos gráficos, el tipo XML y los tipos definidos por el usuario no se pueden utilizar como parámetros en las funciones de tabla PARAMETER CCSID UNICODE (SQLSTATE 560C1).
Las sentencias de SQL siempre se interpretan en la página de códigos de la base de datos. En particular, significa que cada carácter de los literales, literales hexadecimales e identificadores delimitados debe tener una representación en la página de códigos de la base de datos; de lo contrario, el carácter se sustituirá por el carácter de sustitución.

Si la base de datos no es Unicode y se ha especificado un orden de clasificación alternativo en la configuración de la base de datos, las funciones se pueden crear con PARAMETER CCSID ASCII o PARAMETER CCSID UNICODE. Todos los datos de serie que se pasan a la función y desde ella se convertirán a la página de códigos adecuada.

Esta cláusula no se puede especificar con LANGUAGE CPP, LANGUAGE OLE, LANGUAGE JAVA, o LANGUAGE CLR (SQLSTATE 42613).

DETERMINISTIC o NOT DETERMINISTIC

Esta cláusula opcional especifica si la función siempre devuelve los mismos resultados para unos valores argumento determinados (DETERMINISTIC) o si la función depende de ciertos valores de estado que afectan a los resultados (NOT DETERMINISTIC). Es decir, una función DETERMINISTIC siempre debe devolver la misma tabla ante invocaciones sucesivas con entradas idénticas. Con la especificación de NOT DETERMINISTIC, se evitan las optimizaciones que aprovechan el hecho de que las entradas idénticas siempre producen los mismos resultados. Un ejemplo de una función de tabla que no es determinante es aquel que hace referencia a registros especiales, variables globales, funciones no determinantes o secuencias de un modo que afecta al tipo de resultado de la función de tabla.

FENCED o NOT FENCED

Esta cláusula especifica si la función se considera segura (NOT FENCED) o no (FENCED) para ejecutarse en el proceso o espacio de direcciones del entorno operativo del gestor de bases de datos.

Si una función se ha registrado como FENCED, el gestor de bases de datos protege sus recursos internos (por ejemplo, los almacenamientos intermedios de datos) para que la función no pueda acceder a ellos. La mayoría de las funciones tienen la opción de ejecutarse como FENCED o NOT FENCED. En general, una función que se ejecute como FENCED no funcionará tan bien como otra de iguales características que se ejecute como NOT FENCED.

PRECAUCIÓN:

El uso de NOT FENCED en funciones que no se han codificado, revisado ni probado adecuadamente puede comprometer la integridad de la base de datos. Este producto de base de datos está protegido frente a muchas de las anomalías inadvertidas más habituales que podrían producirse, pero no pueden asegurar la integridad completa si se emplean funciones definidas por el usuario NOT FENCED.

Para una función con LANGUAGE OLE o NOT THREADSAFE, sólo puede especificarse FENCED (SQLSTATE 42613).

Si la función es FENCED y tiene la opción NO SQL, no puede especificarse la cláusula AS LOCATOR (SQLSTATE 42613).

Para registrar una función definida por el usuario como NOT FENCED, se necesita autorización SYSADM, autorización DBADM o una autorización especial (CREATE_NOT_FENCED_ROUTINE).

No se pueden crear funciones LANGUAGE CLR definidas por el usuario al especificar la cláusula NOT FENCED (SQLSTATE 42601).

THREADSAFE o NOT THREADSAFE

Especifica si se considera que la función es segura para ejecutarse en el mismo proceso que otras rutinas (THREADSAFE) o no (NOT THREADSAFE).

Si la función se ha definido con un LANGUAGE distinto de OLE:

Si la función se ha definido como THREADSAFE, el gestor de bases de datos puede invocar la función en el mismo proceso que otras rutinas. En general, para ser THREADSAFE, una función no debe utilizar áreas de datos globales o estáticas. En la mayoría de los manuales de consulta de programación se incluye una explicación acerca de cómo se escriben las rutinas THREADSAFE. Las funciones FENCED y NOT FENCED pueden ser THREADSAFE.
Si la función se ha definido como NOT THREADSAFE, el gestor de bases de datos nunca invocará al mismo tiempo la función en el mismo proceso que otra rutina.

Para las funciones FENCED, THREADSAFE es el valor por omisión si el LANGUAGE es JAVA o CLR. Para todos los demás lenguajes, NOT THREADSAFE es el valor por omisión. Si la función se ha definido con LANGUAGE OLE, THREADSAFE no puede especificarse (SQLSTATE 42613).

Para las funciones NOT FENCED, THREADSAFE es el valor por omisión. No puede especificarse NOT THREADSAFE (SQLSTATE 42613).

RETURNS NULL ON NULL INPUT o CALLED ON NULL INPUT

Esta cláusula opcional puede utilizarse para evitar una llamada a la función externa si cualquiera de los argumentos es nulo. Si la función definida por el usuario está definida para no tener ningún parámetro, entonces por supuesto, esta condición de argumento nulo no puede surgir y no importa cómo se haya codificado esta especificación.

Si se especifica RETURNS NULL ON NULL INPUT y, durante la apertura de la función de tabla, cualquiera de los argumentos de la función es nulo, no se invoca la función definida por el usuario. El resultado de la función de tabla será una tabla vacía (una tabla sin ninguna fila).

Si se especifica CALLED ON NULL INPUT, entonces con independencia de si los argumentos son nulos o no, se invoca la función definida por el usuario. Puede devolver un valor nulo o un valor normal (no nulo). Pero corresponde a la UDF comprobar si los valores de argumentos son nulos.

El valor NULL CALL puede utilizarse como sinónimo de CALLED ON NULL INPUT para mantener la compatibilidad con versiones anteriores. De manera similar, puede utilizarse NOT NULL CALL como sinónimo de RETURNS NULL ON NULL INPUT.

READS SQL DATA, NO SQL, CONTAINS SQL

Especifica la clasificación de sentencias SQL que puede ejecutar la función. El gestor de base de datos verifica que las sentencias SQL que emite la función son coherentes con esta especificación.

Para la clasificación de cada sentencia, consulte Sentencias SQL que se pueden ejecutar en rutinas y activadores

El valor predeterminado es READS SQL DATA.

READS SQL DATA: Especifica que la función puede ejecutar sentencias con la clasificación de acceso de datos de READS SQL DATA, CONTAINS SQL, o NO SQL (SQLSTATE 38002 o 42985). La función no puede ejecutar sentencias SQL que modifican datos (SQLSTATE 38003 o 42985).
NO SQL: Especifica que la función sólo puede ejecutar sentencias SQL con una clasificación de acceso de datos de NO SQL. Si se especifican todas las cláusulas ALLOW PARALLEL, EXECUTE ON ALL DATABASE PARTITIONS y RESULT TABLE DISTRIBUTED, sólo estará permitida la opción NO SQL.
CONTAINS SQL: Especifica que la función sólo puede ejecutar sentencias SQL con una clasificación de acceso de datos de CONTAINS SQL o NO SQL (SQLSTATE 38004 o 42985). La función no puede ejecutar sentencias SQL que lean o modifiquen datos (SQLSTATE 38003 o 42985).

STATIC DISPATCH

Esta cláusula opcional indica que, durante la resolución de la función, el servidor de bases de datos elige una función basada en los tipos estáticos (tipos declarados) de los parámetros de la función.

EXTERNAL ACTION o NO EXTERNAL ACTION

Especifica si la función puede realizar una acción que cambie el estado de un objeto que el gestor de bases de datos no gestiona. Un ejemplo de una acción externa es enviar un mensaje o grabar un registro en un archivo. El valor por omisión es EXTERNAL ACTION.

EXTERNAL ACTION: Especifica que la función realiza una acción que cambia el estado de un objeto que el gestor de bases de datos no gestiona.
Una función con acciones externas puede devolver resultados incorrectos si se ejecuta por tareas paralelas. Por ejemplo, si la función envía una nota para cada llamada inicial a esa función, se enviará una nota para cada tarea paralela, en lugar de una nota para la función. Especifique la cláusula DISALLOW PARALLEL en el caso de las funciones que no funcionen bien con paralelismo.
NO EXTERNAL ACTION: Especifica que la función no realiza ninguna acción que cambie el estado de un objeto que el gestor de bases de datos no gestiona. El gestor de bases de datos utiliza esta información durante la optimización de las sentencias de SQL.

NO SCRATCHPAD o SCRATCHPAD longitud

Esta cláusula opcional especifica si debe proporcionarse una memoria de trabajo para una función externa. (Es muy recomendable que las funciones definidas por el usuario sean reentrantes, por lo que una memoria de trabajo proporciona un medio para que la función guarde el estado entre una llamada y la siguiente.)

Si se especifica SCRATCHPAD, cuando se efectúa la primera invocación de la función definida por el usuario, se asigna memoria para que la función externa utilice una memoria de trabajo. En cada invocación de la función definida por el usuario se pasa un argumento adicional a la función externa que indica la dirección de la memoria de trabajo. Esta memoria de trabajo tiene las siguientes características:
- longitud, si se especifica, define el tamaño en bytes de la memoria de trabajo; este valor debe estar comprendido entre 1 y 32.767 (SQLSTATE 42820). El valor por omisión es 100.
- El valor de inicialización consta sólo de ceros hexadecimales: X'00'.
- Su ámbito es la sentencia de SQL. Existe una memoria de trabajo para referencia a la función externa en la sentencia de SQL. Por tanto, si la función UDFX de la sentencia siguiente se define con la palabra clave SCRATCHPAD, se asignarían dos memorias de trabajo.
```
   SELECT A.C1, B.C2
     FROM TABLE (UDFX(:hv1)) AS A,
          TABLE (UDFX(:hv1)) AS B
       WHERE ...
```
- Su contenido se conserva. Se inicializa al principio de la ejecución de la sentencia y puede ser utilizada por la función de tabla externa para guardar el estado de la memoria de trabajo entre una llamada y la siguiente. Si también se especifica la palabra clave FINAL CALL para la UDF, NUNCA se modifica la memoria de trabajo y los recursos anclados en ella deben liberarse cuando se emite la llamada especial FINAL.
  Si se especifica NO FINAL CALL o se acepta el valor por omisión, la función de tabla externa debe borrar tales recursos en la llamada CLOSE, pues el servidor de bases de datos reinicializará la memoria de trabajo en cada llamada OPEN. Esta elección entre FINAL CALL o NO FINAL CALL y el comportamiento asociado de la memoria de trabajo puede ser un factor importante, especialmente cuando la función de tabla se utiliza en una subconsulta o unión, pues es cuando pueden producirse varias llamadas OPEN durante la ejecución de una sentencia.
- Puede utilizarse como punto central de los recursos del sistema (por ejemplo, la memoria) que podría adquirir la función externa. La función podría adquirir la memoria en la primera llamada, conservar su dirección en la memoria de trabajo y acceder a ella en llamadas posteriores.
  (Como se ha indicado anteriormente, la palabra clave FINAL CALL/NO FINAL CALL se utiliza para controlar la reinicialización de la memoria de trabajo y también determina cuándo la función de tabla externa debe liberar los recursos anclados en la memoria de trabajo.)
Si se especifica NO SCRATCHPAD, no se asignará ni pasará ninguna memoria de trabajo a la función externa.

FINAL CALL o NO FINAL CALL

Esta cláusula opcional especifica si debe realizarse una llamada final (y una primera llamada aparte) a una función externa. También controla cuándo debe volver a inicializarse la memoria de trabajo. Si se especifica NO FINAL CALL, el servidor de bases de datos sólo puede realizar tres tipos de llamadas a la función de tabla: open (apertura), fetch (lectura) y close (cierre). En cambio, si se especifica FINAL CALL, además de las llamadas de apertura, lectura y cierre, pueden efectuarse una primera llamada y una llamada final a la función de tabla.

Para las funciones de tabla externa, el argumento tipo-llamada SIEMPRE está presente, sea cual sea la opción que se elija.

Si la llamada final está realizándose porque se ha producido una interrupción o un fin de transacción, puede que la UDF no emita ninguna sentencia de SQL, a excepción del cursor CLOSE (SQLSTATE 38505). Para estas situaciones especiales de la llamada final, se pasa un valor especial en el argumento del tipo de llamada.

No se puede especificar FINAL CALL junto con LANGUAGE CPP.

DISALLOW PARALLEL o ALLOW PARALLEL EXECUTE ON ALL DATABASE PARTITIONS RESULT TABLE DISTRIBUTED

Especifica si, para una única referencia a la función, debe paralelizarse la función.

DISALLOW PARALLEL: Especifica que en cada invocación de la función, la función se invoca en una única partición de base de datos.
ALLOW PARALLEL EXECUTE ON ALL DATABASE PARTITIONS RESULT TABLE DISTRIBUTED: Especifica que en cada invocación de la función, la función se invoca en todas las particiones de base de datos. Se devuelve todos los conjuntos de resultados obtenidos en cada partición de base de datos. La función no puede ejecutar sentencias de SQL (debe especificarse también la cláusula NO SQL).

NO DBINFO o DBINFO

Esta cláusula opcional especifica si se pasará cierta información específica conocida por el servidor de bases de datos a la función como argumento en tiempo de invocación adicional (DBINFO) o no (NO DBINFO). NO DBINFO es el valor por omisión. DBINFO no está soportado para LANGUAGE OLE o PARAMETER TYLE NPSGENERIC (SQLSTATE 42613).

Si se especifica DBINFO, se pasará una estructura que contiene la información siguiente:

Nombre de la base de datos: el nombre de la base de datos conectada actualmente
ID de aplicación: ID de aplicación exclusivo que se establece para cada conexión a la base de datos
ID de autorización de aplicación: el ID de autorización de ejecución de la aplicación, sin tener en cuenta las funciones anidadas entre esta función y la aplicación
Página de códigos: página de códigos de la base de datos
Nombre de esquema: no se puede aplicar a funciones de tabla externas
Nombre de tabla: no se puede aplicar a funciones de tabla externas
Nombre de columna: no se puede aplicar a funciones de tabla externas
Versión o release de la base de datos: la versión, release y nivel de modificación del servidor de la base de datos que invoca la función
Plataforma: el tipo de plataforma del servidor
Números de columna del resultado del método de tabla: matriz de números de la columna del resultado que utiliza la sentencia que hace referencia a la función; esta información permite que la función sólo devuelva los valores de columna necesarios y no todos los valores de ésta
Número de partición de base de datos: el número de partición de base de datos en el que se invoca la función de tabla externa; en un entorno de una partición de base de datos, este valor es 0

CARDINALITY entero

Esta cláusula opcional proporciona una estimación del número esperado de filas que debe devolver la función con fines de optimización. Los valores válidos van de 0 a 9.223.372.036.854.775.807.

Si no se especifica la cláusula CARDINALITY para una función de tabla, asuma un valor finito como valor por omisión (el mismo valor asumido para las tablas para las que el programa de utilidad RUNSTATS no ha reunido estadísticas).

Aviso: Si una función tiene, de hecho, una cardinalidad infinita ( es decir, devuelve una fila cada vez que se llama para ello y nunca devuelve una condición de fin de tabla), las consultas que requieran una condición de fin de tabla para funcionar correctamente serán infinitas y se deberán interrumpir. Las consultas que contienen una cláusula GROUP BY o ORDER BY son ejemplos de esta clase de consultas. Por esta razón, no se recomienda grabar las UDF que tienen cardinalidad infinita.

TRANSFORM GROUP nombre-grupo

Indica el grupo de transformación que se debe utilizar, cuando se invoca la función, para las transformaciones de tipo estructurado definidas por el usuario. Es necesaria una transformación si la definición de la función incluye un tipo estructurado definido por el usuario, en calidad de tipo de datos de parámetro. Si no se especifica esta cláusula, se utiliza el nombre de grupo por omisión, DB2_FUNCTION. Si el nombre-grupo especificado (o tomado por omisión) no está definido para un tipo estructurado referenciado, se produce en error (SQLSTATE 42741). Si una función de transformación necesaria FROM SQL no está definida para el nombre de grupo y tipo estructurado proporcionados, se produce un error (SQLSTATE 42744).

INHERIT SPECIAL REGISTERS

Esta cláusula opcional especifica que los registros especiales que pueden actualizarse de la función heredarán sus valores iniciales del entorno de la sentencia que realiza la invocación. Para una función que se invoca en la sentencia-select de un cursor, los valores iniciales se heredan del entorno cuando se abre el cursor. Para una rutina que se invoca en un objeto anidado (por ejemplo, un activador o una vista), los valores iniciales se heredan del entorno de ejecución (no se heredan de la definición del objeto).

Al proceso que invoca la función no se le devolverá ninguno de los cambios realizados en los registros especiales.

Los registros especiales que no pueden actualizarse como, por ejemplo, los registros especiales de indicación de fecha y hora, reflejan una propiedad de la sentencia que está ejecutándose actualmente y, por lo tanto, se establecen en sus valores por omisión.

NOT SECURED o SECURED

Especifica si la función se considera segura para el control de acceso a filas y columnas. El valor por omisión es NOT SECURED.

NOT SECURED: Indica que la función no se considera segura. Cuando se invoca la función, los argumentos de la función no deben hacer referencia a una columna para la que haya habilitada una máscara de columna y el control de acceso de nivel de columna esté activado para su tabla (SQLSTATE 428HA). Esta norma se aplica a las funciones definidas por el usuario no seguras que se invocan en algún punto de la sentencia.
SECURED: Indica que la función se considera segura. La función debe ser segura cuando se hace referencia a ella en un permiso de fila o una máscara de columna (SQLSTATE 428H8, SQLCODE -20470).

STAY RESIDENT NO

Especifica que la biblioteca que está cargada para la función no va a continuar en la memoria una vez que finaliza la función. Esta cláusula se ignora cuando:

No se especifica la cláusula NOT FENCED.
La opción LANGUAGE se establece en JAVA o CLR.

Normas

En un entorno de base de datos particionada, el uso de SQL en funciones o métodos externos definidos por el usuario no recibe soporte (SQLSTATE 42997).
Sólo las rutinas que se han definido como NO SQL pueden utilizarse para definir una extensión de índice (SQLSTATE 428F8).
Si la función permite SQL, el programa externo no debe intentar acceder a ningún objeto federado (SQLSTATE 55047).
Restricciones de acceso a las tablas Si una función se ha definido como READS SQL DATA, ninguna sentencia de la función podrá acceder a la tabla que la sentencia que ha invocado la función está modificando (SQLSTATE 57053). Por ejemplo, supongamos que la función definida por el usuario BONUS() se ha definido como READS SQL DATA. Si se invoca la sentencia UPDATE EMPLOYEE SET SALARY = SALARY + BONUS(EMPNO), no podrá leerse ninguna sentencia de SQL de la función BONUS desde la tabla EMPLOYEE.

Notas

Al elegir los tipos de datos para los parámetros de una función definida por el usuario, tenga en cuenta las normas para la promoción que afectarán a sus valores de entrada. Por ejemplo, una constante que puede utilizarse como un valor de entrada podría tener un tipo de datos incorporado distinto del que se espera y, todavía más importante, podría no promoverse al tipo de datos que se espera. De acuerdo con las normas para la promoción, suele aconsejarse la utilización de los siguientes tipos de datos para parámetros:
- INTEGER en lugar de SMALLINT
- DOUBLE en lugar de REAL
- VARCHAR en lugar de CHAR
- VARGRAPHIC en lugar de GRAPHIC
Para garantizar la portabilidad de las UDF entre distintas plataformas, se recomienda utilizar los tipos de datos siguientes:
- DOUBLE o REAL en lugar de FLOAT
- DECIMAL en lugar de NUMERIC
- CLOB (o BLOB) en lugar de LONG VARCHAR
La creación de una función con un nombre de esquema que todavía no existe dará como resultado la creación implícita de ese esquema siempre que el ID de autorización de la sentencia disponga de autorización IMPLICIT_SCHEMA. El propietario del esquema es SYSIBM. El privilegio CREATEIN sobre el esquema se otorga a PUBLIC.
Se invocará una rutina Java definida como NOT FENCED como si se hubiese definido como FENCED THREADSAFE.
Privilegios: el definidor de una función siempre recibe el privilegio WITH GRANT OPTION de EXECUTE sobre la función, así como el derecho de descartarla función. Cuando se utiliza la función en una sentencia SQL, el definidor de función debe tener el privilegio EXECUTE en cualquier paquete utilizado por la función o el privilegio EXECUTEIN o la autorización de esquema DATAACCESS en el esquema que contiene los paquetes. .
Establecimiento del valor por omisión: los parámetros de una función que están definidos con un valor por omisión se establecen en su valor por omisión cuando se invoca la función, aunque sólo si no se suministra un valor para el argumento correspondiente o se especifica como DEFAULT, cuando se invoca la función.
Alternativas de sintaxis: Las siguientes alternativas de sintaxis reciben soporte para mantener la compatibilidad con las versiones anteriores de este producto de base de datos y con otros productos de base de datos. Estas alternativas no son estándar y no deberían utilizarse.
- PARAMETER STYLE DB2SQL puede especificarse en lugar de PARAMETER STYLE SQL
- NOT VARIANT puede especificarse en lugar de DETERMINISTIC
- VARIANT puede especificarse en lugar de NOT DETERMINISTIC
- NULL CALL puede especificarse en lugar de CALLED ON NULL INPUT
- NOT NULL CALL puede especificarse en lugar de RETURNS NULL ON NULL INPUT
- DB2GENRL puede especificarse en lugar de DB2GENERAL
La sintaxis siguiente se acepta como comportamiento por omisión:
- ASUTIME NO LIMIT
- NO COLLID
- PROGRAM TYPE SUB
- CCSID UNICODE en una base de datos Unicode
- CCSID ASCII en una base de datos que no es Unicode si no se especifica PARAMETER CCSID UNICODE
Creación de una función segura: Por lo general, los usuarios con autorización SECADM no tienen privilegios para crear objetos de base de datos, como activadores y funciones. Suelen examinar los datos a los que accede una función, comprobar que son seguros y, a continuación, otorgar la autorización CREATE_SECURE_OBJECT a quien ya tenga los privilegios necesarios para crear una función segura definida por el usuario. Una vez creada la función, revocarán la autorización CREATE_SECURE_OBJECT al propietario de la función.
El atributo SECURED se considera una aserción que declara que el usuario ha establecido un procedimiento de auditoría de control de todos los cambios en la función definida por el usuario. El gestor de bases de datos presupone que ese procedimiento de auditoría de control está en vigor para todas las sentencias ALTER FUNCTION posteriores o cambios en los paquetes externos.
Invocación de otras funciones definidas por el usuario en una función segura: Si una función segura definida por el usuario invoca otras funciones definidas por el usuario, el gestor de bases de datos no valida si esas funciones definidas por el usuario anidadas tienen el atributo SECURED. Si esas funciones anidadas pueden acceder a datos confidenciales, el usuario con autorización SECADM tiene que garantizar que esas funciones pueden acceder a esos datos y que se ha establecido un procedimiento de auditoría de control de cambios para todos los cambios en esas funciones.
Sustitución de una función existente de manera que el atributo seguro cambia (de SECURED a NOT SECURED y viceversa): Los paquetes y las sentencias de SQL colocadas dinámicamente en memoria caché que dependen de la función pueden quedar invalidadas porque el atributo seguro afecta a la selección de la vía de acceso de las sentencias que implican tablas para las que se ha activado el control de acceso de nivel de fila o columna.
Funciones EXTERNAL ACTION: Si se invoca una función EXTERNAL ACTION en otra lista que no sea la lista de selección más externa, los resultados son imprevisibles, ya que el número de veces que se invoca la función variará en función del plan de acceso utilizado.

Ejemplos

Ejemplo 1: El ejemplo siguiente registra una función de tabla escrita para devolver una fila que consta de una única columna de identificador de documento para cada documento conocido en un sistema de gestión de texto. El primer parámetro coincide con un área de temas determinada y el segundo parámetro contiene una serie determinada.
Dentro del contexto de una sola sesión, la UDF siempre devolverá la misma tabla y, por lo tanto, se define como DETERMINISTIC. Observe que la cláusula RETURNS que define la salida de DOCMATCH. Debe especificarse FINAL CALL para cada función de tabla. Además, se añade la palabra clave DISALLOW PARALLEL porque las funciones de tabla no pueden funcionar en paralelo. Aunque el tamaño de la salida para DOCMATCH es muy variable, el valor CARDINALITY 20 es representativo y se especifica para ayudar al optimizador de la base de datos.
```
   CREATE FUNCTION DOCMATCH (VARCHAR(30), VARCHAR(255))
     RETURNS TABLE (DOC_ID CHAR(16))
     EXTERNAL NAME '/common/docfuncs/rajiv/udfmatch'
     LANGUAGE C
     PARAMETER STYLE SQL
     NO SQL
     DETERMINISTIC
     NO EXTERNAL ACTION
     NOT FENCED
     SCRATCHPAD
     FINAL CALL
     DISALLOW PARALLEL
     CARDINALITY 20
```

Ejemplo 2: El siguiente ejemplo registra una función de tabla OLE que se utiliza para recuperar la información de cabecera de mensaje y el texto de mensaje parcial de los mensajes en Microsoft Exchange.

   CREATE FUNCTION MAIL()
     RETURNS TABLE (TIMERECEIVED DATE,
                    SUBJECT VARCHAR(15),
                    SIZE INTEGER,
                    TEXT VARCHAR(30))
     EXTERNAL NAME 'tfmail.header!list'
     LANGUAGE OLE
     PARAMETER STYLE SQL
     NOT DETERMINISTIC
     FENCED
     CALLED ON NULL INPUT
     SCRATCHPAD
     FINAL CALL
     NO SQL
     EXTERNAL ACTION
     DISALLOW PARALLEL