Funciones

Una función es una operación denotada por un nombre de función seguido por uno o más operandos que se incluyen entre paréntesis.

Una función representa una relación entre un conjunto de valores de entrada y un conjunto de valores de resultado. Los valores de entrada de una función se denominan argumentos. Por ejemplo, se pueden pasar a la función TIMESTAMP argumentos del tipo DATE y TIME y el resultado será TIMESTAMP.

Existen varias formas de clasificar las funciones.

Una forma es clasificar las funciones como incorporadas o definidas por el usuario.

Las funciones incorporadas son funciones que se proporcionan con el gestor de bases de datos. Las funciones incorporadas incluyen funciones agregadas (por ejemplo, AVG), las funciones de operador (por ejemplo, +), las funciones de conversión (por ejemplo, DECIMAL), las funciones escalares (por ejemplo, CEILING) y las funciones de tabla (por ejemplo, BASE_TABLE). Las funciones incorporadas generalmente se definen en esquemas que comienzan por 'SYS' (por ejemplo, SYSIBM, SYSFUN y SYSIBMADM), aunque algunas también se definen en esquemas que comienzan por 'DB2' (por ejemplo, DB2MQ).
Las funciones definidas por el usuario son funciones que se crean mediante una sentencia de definición de datos SQL y que se registran en el gestor de bases de datos en el catálogo. Las funciones de esquema definidas por el usuario se crean utilizando la sentencia CREATE FUNCTION.Las funciones de módulo definidas por el usuario se crean utilizando las sentencias ALTER MODULE ADD FUNCTION o ALTER MODULE PUBLISH FUNCTION. Se proporciona un conjunto de funciones de módulo definidas por el usuario con el gestor de bases de datos en un conjunto de módulos en un esquema denominado SYSIBMADM. Una función definida por el usuario reside en el esquema donde se ha creado o en el módulo donde se ha añadido o publicado.
Las funciones definidas por el usuario amplían las posibilidades del sistema de bases de datos añadiendo definiciones de funciones (proporcionadas por usuarios o proveedores) que pueden aplicarse en el propio núcleo de la base de datos. La ampliación de las funciones de la base de datos permite que la base de datos explote las mismas funciones en su núcleo que las que utiliza una aplicación, proporcionando más sinergia entre la aplicación y la base de datos.

Otra forma de clasificar una función definida por el usuario es como una función externa, una función SQL, una función derivada o una función de interfaz:

Una función externa se define en la base de datos con una referencia a una biblioteca de códigos objeto y una función en dicha biblioteca que se ejecutará cuando se invoque la función. Las funciones externas no pueden ser funciones agregadas.
Una función de SQL se define en la base de datos sólo a través de sentencias SQL, incluida, como mínimo, una sentencia RETURN. Puede devolver un valor escalar, una fila o una tabla. Las funciones SQL no pueden ser funciones agregadas.
Una función derivada se define para la base de datos con una referencia a otra función incorporada o definida por el usuario que ya se conoce en la base de datos. Las funciones derivadas pueden ser funciones escalares o funciones agregadas. Son útiles para dar soporte a funciones existentes con tipos definidos por el usuario.
Una función de interfaz se define para la base de datos con una referencia a varias rutinas definidas por el usuario que ya se conocen en la base de datos. Las funciones de interfaz pueden ser únicamente funciones de agregación.

Otra forma de clasificar las funciones es como función escalar, agregada, de fila o de tabla, según los valores de los datos de entrada y de los valores de resultado. Una función escalar es una función que devuelve una respuesta de un sólo valor cada vez que se invoca. Por ejemplo, la función incorporada SUBSTR() es una función escalar. Las UDF escalares pueden ser externas o derivadas.

Una función agregada es aquella a la que se pasa conceptualmente un conjunto de valores similares (una columna) y que devuelve una respuesta con un sólo valor. Un ejemplo de una función de agregación es la función incorporada AVG (). Se puede definir una UDF de columna, que se origina en una de las funciones agregadas incorporadas. Es útil para tipos diferenciados. Por ejemplo, si hay definido un tipo diferenciado SHOESIZE con el tipo base INTEGER, se puede definir una UDF AVG(SHOESIZE), que se origine en la función incorporada AVG(INTEGER) y se trataría de una función agregada. Se puede definir una función de interfaz agregada que tenga su origen en varios rutinas definidas por el usuario.

Una función de fila es una función que devuelve una fila de valores. Puede utilizarse en un contexto que da soporte a una expresión de fila. También se puede utilizar como función de transformación, que correlaciona valores de atributos de un tipo estructurado con valores de una fila. Las funciones de fila deben estar definidas como funciones de SQL.

Una función de tabla es una función que devuelve una tabla a la sentencia de SQL donde se invoca la función. Sólo se puede hacer referencia a la función en la cláusula FROM de una sentencia SELECT. Una función de este tipo puede utilizarse para aplicar la potencia de proceso de lenguaje SQL a datos que no residen en la base de datos o para convertir tales datos en una tabla de la base de datos. Una función de tabla puede leer un archivo, obtener datos de la web o acceder a una base de datos de Lotus Notes® y devolver una tabla de resultados. Esta información puede unirse a otras tablas de la base de datos. Una función de tabla se puede definir como una función externa o como una función de SQL. (Una función de tabla no puede ser una función derivada).

Signaturas de función

Una función de esquema se identifica por su nombre de esquema, un nombre de función, el número de parámetros y los tipos de datos de sus parámetros. Una función de módulo se identifica por su nombre de esquema, su nombre de módulo, un nombre de función, el número de parámetros y los tipos de datos de sus parámetros. Esta identificación de una función de esquema o una función de módulo se denomina signatura de función, que debe ser exclusiva en la base de datos; por ejemplo, TEST.RISK(INTEGER). Varias funciones pueden tener el mismo nombre dentro de un esquema o un módulo, siempre que el número de parámetros o bien los tipos de datos de los parámetros sean diferentes. Un nombre de función para el que existen múltiples instancias de función con el mismo número de parámetros se llama función sobrecargada. Un nombre de función puede estar sobrecargado dentro de un esquema, en cuyo caso hay más de una función con el mismo nombre y con el mismo número de parámetros en el esquema. De igual forma, un nombre de función puede estar sobrecargado dentro de un módulo, en cuyo caso hay más de una función con el mismo nombre y con el mismo número de parámetros en el módulo. Estas funciones deben tener tipos de datos de parámetros distintos. Las funciones también pueden estar sobrecargadas dentro de los esquemas de una vía de acceso de SQL, en cuyo caso hay más de una función con el mismo nombre y con el mismo número de parámetros en los distintos esquemas de la vía de acceso de SQL. Estas funciones no deben tener necesariamente tipos de datos de parámetros distintos.

Invocación de funciones

Las referencias a una función deben ser conformes con la sintaxis siguiente:

argument

Notes:

¹ The ALL or DISTINCT keyword can be specified for certain built-in aggregate functions or a user-defined function that is sourced on certain built-in aggregate functions. The ALL keyword can be specified for an aggregate interface function.

En la sintaxis mostrada anteriormente, expresión y expresión-fila no pueden incluir una función agregada. Consulte Expresiones para conocer otras normas de expresión.

Una función se invoca haciendo referencia (en un contexto que lo permita) a su nombre calificado o no calificado, seguido por la lista de argumentos, entre paréntesis. Los calificadores posibles para un nombre de función son:

Un nombre de esquema
Uno nombre de módulo no calificado
Un nombre de módulo calificado mediante esquema

El calificador que se utiliza al invocar una función determina el ámbito empleado para buscar una función coincidente.

Si se utiliza un nombre de módulo calificado mediante esquema como calificador, el ámbito será el módulo especificado.
Si se utiliza un único identificador como calificador, el ámbito incluye:
- El esquema que coincide con el calificador
- Uno de los módulos siguientes:
  - El módulo que realiza la invocación, si el nombre del módulo que realiza la invocación coincide con el calificador
  - El primer módulo de un esquema en la vía de acceso de SQL que coincide con el calificador
Si no se emplea calificador, el ámbito incluye los esquemas de la vía de acceso de SQL y, si la función se invoca desde un objeto de módulo, el mismo módulo desde el que se invoca la función.

Para las sentencias de SQL estático, la vía de acceso de SQL se especifica mediante la utilización de la opción de vinculación FUNCPATH. Para las sentencias de SQL dinámico, la vía de acceso de SQL es el valor del registro especial CURRENT PATH.

Cuando se invoca una función, el gestor de bases de datos debe determinar la función que se debe ejecutar. Este proceso se denomina resolución de funciones y se aplica tanto a las funciones incorporadas como a las definidas por el usuario. Se recomienda que las invocaciones de funciones que pretendan invocar una función definida por el usuario sean completamente calificadas. De esta forma, se mejora el rendimiento de la resolución de funciones y se impide que se produzcan resoluciones de funciones inesperadas al añadir funciones nuevas u otorgar privilegios.

Un argumento es un valor que se pasa a una función en una invocación o la especificación de DEFAULT. Cuando se invoca una función en SQL, se pasa una lista de cero o más argumentos. Son argumentos posicionales en tanto que la semántica de dichos argumentos viene determinada por su posición en la lista de argumentos. Un parámetro es una definición formal de una entrada para una función o una salida de una función. Cuando una función está definida en la base de datos, ya sea internamente (una función incorporada) o por el usuario (una función definida por el usuario), se especifican sus parámetros (cero o más) y el orden de sus definiciones define su posición y su semántica. Por lo tanto, cada parámetro es una entrada posicional particular para una función o una salida de una función. En la invocación, un argumento se asigna a un parámetro mediante la sintaxis de posición o la sintaxis por nombre. Si se utiliza la sintaxis de posición, un argumento corresponde a un parámetro determinado en virtud de la posición que éste ocupe en la lista de argumentos. Si se utiliza la sintaxis por nombre, un argumento corresponde a un parámetro determinado en función del nombre del parámetro. Cuando se asigna un argumento a un parámetro utilizando la sintaxis por nombre, todos los argumentos que siguen a éste también deben asignarse utilizando la sintaxis por nombre (SQLSTATE 4274K). El nombre de un argumento con nombre puede aparecer solamente una vez en una invocación de función (SQLSTATE 4274K). En los casos en los que los tipos de datos de los argumentos de la invocación de la función no coinciden con los tipos de datos de los parámetros de la función seleccionada, los argumentos se convierten al tipo de datos del parámetro durante la ejecución, utilizando las mismas normas que para la asignación a columnas. También se incluye el caso en el que la precisión, escala o longitud difiere entre el argumento y el parámetro. En los casos en los que los argumentos de la invocación de función son la especificación de DEFAULT, el valor real utilizado para el argumento es el valor especificado como valor por omisión para el parámetro correspondiente en la definición de la función. Si no se ha definido ningún valor por omisión para el parámetro, se utiliza el valor nulo. Si se utiliza como argumento una expresión sin tipo (un marcador de parámetro, una palabra clave NULL o una palabra clave DEFAULT), el tipo de datos asociado con el argumento está determinado por el tipo de datos del parámetro de la función seleccionada.

El acceso a las funciones de esquema se controla mediante el privilegio EXECUTE sobre las funciones de esquema. Si el ID de autorización de la sentencia que invoca la función no tiene el privilegio EXECUTE, el algoritmo de resolución de función no tendrá en cuenta la función de esquema aunque ésta se corresponda mucho mejor. En las funciones incorporadas de los esquemas SYSIBM y SYSFUN, el privilegio EXECUTE se otorga a PUBLIC de forma implícita.

El acceso a las funciones de módulo se controla mediante el privilegio EXECUTE sobre el módulo para todas las funciones pertenecientes al módulo. El ID de autorización de la sentencia que invoca la función puede no tener el privilegio EXECUTE sobre un módulo. En estos casos, y a diferencia de las funciones de esquema, el algoritmo de resolución de función continúa teniendo en cuenta las funciones de módulo de dicho módulo, aunque no pueden ejecutarse.

Cuando se invoca la sentencia definida por el usuario, el valor de cada uno de sus argumentos se asigna, utilizando la asignación de almacenamiento, al parámetro correspondiente de la función. Se pasa el control a las funciones externas de acuerdo con los convenios de llamada del lenguaje principal. Una vez finalizada la ejecución de una función escalar definida por el usuario o una función agregada definida por el usuario, el resultado de la función se asigna, utilizando la asignación de almacenamiento, al tipo de datos del resultado. Para obtener detalles sobre las normas de asignación, consulte Asignaciones y comparaciones.

Sólo se puede hacer referencia a las funciones de tabla en la cláusula FROM de una subselección. Para obtener más información sobre cómo hacer referencia a una función de tabla, consulte referencia-tabla.

Resolución de función

Tras invocar una función, el gestor de bases de datos debe determinar la función que se debe ejecutar. Este proceso se denomina resolución de funciones y se aplica tanto a las funciones incorporadas como a las definidas por el usuario.

El gestor de bases de datos en primer lugar determina el conjunto de funciones candidatas según la información siguiente:

La calificación del nombre de la función invocada
El contexto que invoca la función
El nombre no calificado de la función invocada
El número de argumentos especificado
Los nombres de argumentos que se hayan especificado
La autorización de las funciones de esquema

Consulte Determinación del conjunto de funciones candidatas para obtener más detalles.

A continuación, el gestor de bases de datos determina la mejor opción del conjunto de funciones candidatas basándose en los tipos de datos de los argumentos de la función invocada, en comparación con los tipos de datos de los parámetros de las funciones pertenecientes al conjunto de funciones candidatas. La vía de acceso de SQL y el número de parámetros también se tiene en cuenta. Consulte Determinación del mejor ajuste para obtener más detalles.

Una vez seleccionada una función, todavía puede devolverse un error por uno de estos motivos:

Si se selecciona una función de módulo y la función se invoca desde fuera de un módulo o desde dentro de un objeto de módulo, y si el calificador no coincide con el nombre del módulo de contexto, el ID de autorización de la sentencia que invocó la función debe disponer del privilegio EXECUTE sobre el módulo que contiene la función seleccionada (SQLSTATE 42501).
Si selecciona una función, su uso satisfactorio depende de si se va a invocar en un contexto en el que se permita el resultado devuelto. Por ejemplo, si la función devuelve una tabla donde no se permite una tabla, se devuelve un error (SQLSTATE 42887).
Si se selecciona una función de conversión, ya sea incorporada o definida por el usuario, y se necesitaría convertir (no promocionar) implícitamente cualquier argumento al tipo de datos del parámetro, se devuelve un error (SQLSTATE 42884).
Si la invocación de una función implica un argumento con un tipo de fila sin nombre, se devuelve un error (SQLSTATE 42884) si se produce una de las siguientes condiciones:
- El número de campos del argumento no coincide con el número de campos del parámetro.
- Los tipos de datos de los campos del argumento no pueden asignarse al tipo de datos correspondiente de los campos del parámetro.

Determinación del conjunto de funciones candidatas

Dejar que A sea el número de argumentos en la invocación de una función.
Dejar que P sea el número de parámetros en la signatura de una función.
Dejar que N sea el número de parámetros en la signatura de una función sin un valor por omisión.

Las funciones candidatas para la resolución de una invocación de función se seleccionan según los criterios siguientes:

Cada función candidata tiene un nombre coincidente y un número de parámetros aplicable. Un número aplicable de parámetros satisface la condición N ≤ A ≤ P..
Cada función candidata tiene parámetros que hacen que para cada argumento con nombre de la invocación de función exista un parámetro con un nombre coincidente que todavía no corresponde a un argumento de posición (sin nombre).
Cada parámetro de una función candidata que no tenga un argumento correspondiente en la invocación de la función, especificado por posición o por nombre, se define con un valor por omisión.
Cada función candidata de un conjunto de uno o varios esquemas tiene el privilegio EXECUTE asociado con el ID de autorización de la sentencia que invoca la función.
Cada función candidata de un módulo que no sea el de contexto es una función de módulo publicado.

Las funciones seleccionadas para el conjunto de funciones candidatas proceden de uno o varios de los espacios de búsqueda siguientes.

El módulo de contexto, es decir, el módulo que contiene el objeto de módulo que invocó la función
Un conjunto de uno o varios esquemas
Un módulo distinto del módulo de contexto

Los espacios de búsqueda específicos considerados se ven afectados por la calificación del nombre de la función invocada.

Invocación de función calificada: cuando se invoca una función con un nombre de función y un calificador, el gestor de bases de datos utiliza el calificador y, en algunos casos, el contexto de la función invocada para determinar el conjunto de funciones candidatas.
1. Si se invoca una función desde un objeto de módulo mediante un nombre de función con un calificador, el gestor de bases de datos considera si el calificador coincide con el nombre del módulo de contexto. Si el calificador es un sólo identificador, el nombre de esquema del módulo se ignora al determinar una coincidencia. Si el calificador es un identificador de dos partes, se compara con el nombre de módulo calificado mediante esquema al determinar una coincidencia. Si el calificador coincide con el nombre de módulo de contexto, el gestor de bases de datos busca en el módulo de contexto las funciones candidatas.
  Si se encuentran una o varias funciones candidatas en el módulo de contexto, se procesa este conjunto de funciones candidatas para determinar cuál es la mejor opción, sin tener en consideración las otras funciones candidatas posibles de otros espacios de búsqueda (véase Determinación de la mejor opción). En caso contrario, se continúa con el siguiente espacio de búsqueda.
2. Si el calificador es un único identificador, el gestor de bases de datos considera el calificador como un nombre de esquema y busca en ese esquema las funciones candidatas.
  Si se encuentran una o varias funciones candidatas en el esquema, se procesa este conjunto de funciones candidatas para determinar cuál es la mejor opción, sin tener en consideración las otras funciones candidatas posibles de otros espacios de búsqueda (véase Determinación de la mejor opción). En caso contrario, se continúa con el siguiente espacio de búsqueda, si procede.
3. Si se invoca la función desde fuera de un módulo o el calificador no coincide con el nombre del módulo de contexto cuando se le invoca desde un objeto de módulo, el gestor de bases de datos considera el calificador como un nombre de módulo. Dejando de lado el privilegio EXECUTE sobre los módulos, el gestor de bases de datos selecciona a continuación el primer módulo coincidente, según los criterios siguientes:
  - Si el nombre de módulo está calificado con un nombre de esquema, selecciona el módulo con dicho nombre de esquema y nombre de módulo.
  - Si el nombre del módulo no está calificado con un nombre de esquema, selecciona el módulo con dicho nombre de módulo que se encuentra en el primer esquema de la vía de acceso de SQL.
  - Si no se encuentra el módulo mediante la vía de acceso de SQL, selecciona el alias público de módulo con dicho nombre de módulo.
  Si no se encuentra un módulo coincidente, no existen funciones candidatas. Si se encuentra un módulo coincidente, el gestor de bases de datos busca en el módulo seleccionado las funciones candidatas.
  Si se encuentran una o varias funciones candidatas en los módulos seleccionados, se procesa este conjunto de funciones candidatas para determinar cuál es la mejor opción (véase Determinación de la mejor opción).
Invocación de función no calificada: cuando se invoca una función sin un calificador, el gestor de bases de datos considera el contexto de la función invocada para determinar los conjuntos de funciones candidatas.
1. Si se invoca una función con un nombre de función no calificado desde un objeto de módulo, el gestor de bases de datos busca en el módulo de contexto las funciones candidatas.
  Si se encuentran una o varias funciones candidatas en el módulo de contexto, estas funciones candidatas se unen a las funciones candidatas de los esquemas de la vía de acceso de SQL (véase el punto siguiente).
2. Si se invoca una función con un nombre de función no calificado, tanto desde dentro de un objeto de módulo como desde fuera de un módulo, el gestor de bases de datos busca la lista de esquemas en la vía de acceso de SQL para resolver la instancia de función que se debe ejecutar. Por cada esquema de la vía de acceso de SQL (consulte Vía de acceso de SQL), el gestor de bases de datos buscará las funciones candidatas en el esquema.
  Si se encuentran una o varias funciones candidatas en los esquemas de la vía de acceso de SQL, estas funciones candidatas se unen a las funciones candidatas del módulo de contexto (véase el punto anterior). Este conjunto de funciones candidatas se procesa para determinar cuál es la mejor opción (véase Determinación de la mejor opción).

Si el gestor de bases de datos no encuentra ninguna función candidata, se devuelve un error (SQLSTATE 42884).

Determinación de la mejor opción

El conjunto de funciones candidatas puede contener tanto una función como varias funciones con el mismo nombre. En ambos casos, los tipos de datos de los parámetros, la posición del esquema en la vía de acceso de SQL y el número total de los parámetros de cada función perteneciente al conjunto de funciones candidatas se utilizan para determinar si la función cumple los requisitos de mejor opción.

Si el conjunto de funciones candidatas contiene más de una función y se utilizan argumentos con nombre en la invocación de la función, la posición ordinal del parámetro correspondiente a un argumento con nombre debe ser la misma para todas las funciones candidatas (SQLSTATE 4274K).

El término conjunto de parámetros se utiliza para hacer referencia a todos los parámetros que ocupan la misma posición en las listas de parámetros (en las que haya uno de estos parámetros) para el conjunto de funciones candidatas. El argumento correspondiente de un parámetro se determina según el modo en que se especifican los argumentos en la invocación de la función. En el caso de los argumentos de posición, el argumento correspondiente para un parámetro es el argumento que está en la misma posición en la invocación de la función que el parámetro en la lista de parámetros de la función candidata. En el caso de los argumentos con nombre, el argumento correspondiente para un parámetro es el argumento que tiene el mismo nombre que el parámetro. En este caso, el orden de los argumentos en la invocación de la función no se tiene en cuenta al determinar el valor más apropiado. Si el número de parámetros en una función candidata es mayor que el número de argumentos en la invocación de la función, cada parámetro que no tenga un argumento correspondiente se procesa como si tuviese un argumento correspondiente con la palabra clave DEFAULT como valor.

Los pasos siguientes se utilizan para determinar la función más apropiada:

Step 1: Considering arguments that are typed expressions

El gestor de bases de datos determina cuál es la función, o el conjunto de funciones, que mejor se adapta a los requisitos de mejor opción para la invocación, comparando el tipo de datos de cada parámetro con el tipo de datos del argumento correspondiente.

Cuando se determina si el tipo de datos de un parámetro es el mismo que el tipo de datos del argumento correspondiente:

Los sinónimos de los tipos de datos coinciden. Por ejemplo, FLOAT y DOUBLE se consideran iguales.
Los atributos de un tipo de datos como la longitud, la precisión, la escala y la página de códigos se ignoran. Por lo tanto, se considera que CHAR(8) y CHAR(35) son iguales, como lo son DECIMAL(11,2) y DECIMAL(4,3).

Se obtiene un subconjunto de funciones candidatas considerando sólo las funciones para las que el tipo de datos de cada argumento de la invocación de función que no es una expresión con tipo coincide con el tipo de datos del parámetro correspondiente de la instancia de función o se puede promocionar a éste. Si el argumento de la invocación de función es una expresión sin tipo, el tipo de datos del parámetro correspondiente puede ser cualquiera. La lista de prioridades para la promoción de tipos de datos en Promoción de tipos de datos muestra los tipos de datos que se ajustan (teniendo en cuenta la promoción) para cada tipo de datos en el orden de mejor a peor. Si este subconjunto no está vacío, el mejor ajuste se determina utilizando el proceso promocional en este subconjunto de funciones candidatas. Si este subconjunto está vacío, el mejor ajuste se determinará utilizando el proceso convertible en el conjunto original de funciones candidatas.

Proceso promocionable

Este proceso determina el tipo más apropiado teniendo en cuenta solamente si los argumentos de la invocación de la función coinciden o pueden promocionarse al tipo de datos del parámetro correspondiente de la definición de función. Para el subconjunto de funciones candidatas, las listas de parámetros se procesan de izquierda a derecha: se procesa el conjunto de parámetros que ocupa la primera posición del subconjunto de funciones candidatas antes de pasar al conjunto de parámetros que ocupa la segunda posición, y así sucesivamente. Los pasos siguientes se utilizan para eliminar las funciones candidatas del subconjunto de funciones candidatas (en lo que concierne solamente a la promoción):

Si una función candidata tiene un parámetro en el que el tipo de datos del argumento correspondiente es más apropiado (en lo que concierne solamente a la promoción) para el tipo de datos del parámetro que cualquier otra función candidata, las funciones candidatas que no sean igual de apropiadas para la invocación de función se eliminan. La lista de prioridades para la promoción de tipos de datos en Promoción de tipos de datos muestra los tipos de datos que se ajustan (teniendo en cuenta la promoción) para cada tipo de datos en el orden de mejor a peor.
Si el tipo de datos del argumento correspondiente es una expresión sin tipo, no se elimina ninguna función candidata.
Estos pasos se repiten para el siguiente conjunto de parámetros de las restantes funciones candidatas hasta que no quedan más conjuntos de parámetros.

Proceso convertible

Este proceso determina el tipo más apropiado teniendo en cuenta en primer lugar, para cada parámetro, si el tipo de datos del argumento correspondiente en la invocación de la función coincide o puede promocionarse al tipo de datos del parámetro de la definición de función. A continuación, para cada conjunto de parámetros en el que ningún argumento correspondiente tenga un tipo de datos promocionable, el gestor de bases de datos considera, para cada parámetro, si el tipo de datos del argumento correspondiente se puede convertir implícitamente para la resolución de la función al tipo de datos del parámetro.

Para el conjunto de funciones candidatas, los parámetros de las listas de parámetros se procesan de izquierda a derecha: se procesa el conjunto de parámetros que ocupa la primera posición entre todas las funciones candidatas antes de pasar al conjunto de parámetros que ocupa la segunda posición, y así sucesivamente. Los pasos siguientes se utilizan para eliminar las funciones candidatas del conjunto de funciones candidatas (en lo que concierne solamente a la promoción):

Si una función candidata tiene un parámetro en el que el tipo de datos del argumento correspondiente es más apropiado (en lo que concierne solamente a la promoción) para el tipo de datos del parámetro que cualquier otra función candidata, las funciones candidatas que no sean igual de apropiadas para la invocación de función se eliminan. La lista de prioridades para la promoción de tipos de datos en Promoción de tipos de datos muestra los tipos de datos que se ajustan (teniendo en cuenta la promoción) para cada tipo de datos en el orden de mejor a peor.
Si el tipo de datos del argumento correspondiente no es promocionable (lo que incluye los casos en los que el argumento correspondiente es una expresión sin tipo) al tipo de datos del parámetro de ninguna función candidata, no se elimina ninguna función candidata.
Estos pasos se repiten para el siguiente conjunto de parámetros de las restantes funciones candidatas hasta que no quedan más conjuntos de parámetros.

Si al menos un conjunto de parámetros no tiene ningún argumento correspondiente apropiado (en lo que concierne solamente a la promoción) y el argumento correspondiente del conjunto de parámetros tiene un tipo de datos, el gestor de bases de datos compara cada conjunto de parámetros de este tipo de izquierda a derecha. Los pasos siguientes se utilizan para eliminar las funciones candidatas del conjunto de funciones candidatas (en lo que concierne a la conversión implícita).

Si todos los tipos de datos del conjunto de parámetros para todas las funciones candidatas restantes no pertenecen a la misma lista de prioridades de tipos de datos, tal como se especifica en Promoción de tipos de datos, se devuelve un error (SQLSTATE 428F5).
Si el tipo de datos de los argumentos correspondientes no puede convertirse de forma implícita en el tipo de datos de los parámetros, como se indica en "Conversión implícita para la resolución de funciones", se devuelve un error (SQLSTATE 42884).
Si una función candidata tiene un parámetro en el que el tipo de datos del argumento correspondiente es más apropiado (en lo que concierne a la conversión implícita) para el tipo de datos del parámetro que cualquier otra función candidata, se eliminan las funciones candidatas que no sean igual de apropiadas para la invocación de función. La lista de tipos de datos en Conversión implícita para resolución de funciones muestra el tipo de datos que mejor encaja (teniendo en cuenta la conversión implícita).
Estos pasos se repiten para el siguiente conjunto de parámetros que no tiene ningún argumento correspondiente apropiado (en lo que concierne solamente a la promoción) y el argumento correspondiente del conjunto de parámetros tiene un tipo de datos, hasta que no quedan más conjuntos de parámetros de este tipo o se produce un error.

Step 2: Considering SQL path

Si queda más de una función candidata y existe un módulo de contexto que sigue incluyendo funciones candidatas, el gestor de bases de datos selecciona esas funciones. Si no hay ningún módulo de contexto o no queda ninguna función candidata en el módulo de contexto, el gestor de bases de datos selecciona las funciones candidatas cuyo esquema aparece antes en la vía de acceso de SQL.

Step 3: Considering number of arguments in the function invocation

Si queda más de una función candidata y si una de ellas tiene un número de parámetros menor o igual que el número de parámetros de las otras funciones candidatas, se eliminan las funciones candidatas que tengan un número mayor de parámetros.

Step 4: Considering arguments that are untyped expressions

Si queda más de una función candidata y al menos un conjunto de parámetros tiene un argumento correspondiente que sea una expresión sin tipo, el gestor de bases de datos compara cada conjunto de parámetros de este tipo de izquierda a derecha. Los pasos siguientes se utilizan para eliminar las funciones candidatas del conjunto de funciones candidatas:

Si todos los tipos de datos del conjunto de parámetros para todas las funciones candidatas restantes no pertenecen a la misma lista de prioridades de tipos de datos, tal como se especifica en Promoción de tipos de datos, se devuelve un error (SQLSTATE 428F5).
Si el tipo de datos del parámetro de una función candidata está más a la izquierda en el orden de tipos de datos para la conversión implícita que el de cualquier otra función candidata, se eliminan las funciones candidatas en las que el tipo de datos del parámetro esté más a la derecha en el orden de tipos de datos. La lista de tipos de datos que aparece en "Conversión implícita para la resolución de funciones" muestra el orden de tipos de datos para la conversión implícita.

Si aún quedan varias funciones candidatas, se devuelve un error (SQLSTATE 428F5).

Conversión implícita para la resolución de funciones

La conversión implícita para la resolución de funciones no recibe soporte para argumentos con un tipo definido por el usuario, un tipo de referencia o un tipo de datos XML. Tampoco está soportada en funciones de conversión incorporadas o definidas por el usuario. Recibe soporte en los casos siguientes:

Un valor de un tipo de datos se puede convertir a cualquier otro tipo de datos que esté en la misma lista de prioridad de tipo de datos, tal como se especifica en Promoción de tipos de datos.
Se puede convertir un tipo de datos numérico o de datos de fecha y hora a:
- En una base de datos Unicode, un tipo de datos de carácter distinto a CLOB o un tipo de datos gráficos distinto a DBCLOB.
- En una base de datos no Unicode, un tipo de datos de caracteres distinto a CLOB.
Un tipo de datos de caracteres distinto a CLOB se puede convertir a un tipo de datos numérico o de datos de fecha y hora.
En una base de datos Unicode, un tipo de datos gráficos distinto a DBCLOB se puede convertir a un tipo de datos numéricos o de fecha y hora.
Un carácter FOR BIT DATA se puede convertir a un tipo de datos de serie binaria.
Un tipo de datos de serie binaria se puede convertir a un carácter FOR BIT DATA.
Un tipo de datos TIMESTAMP se puede convertir a un tipo de datos TIME.
Un tipo de datos BOOLEAN se puede convertir a un tipo de datos de entero binario, un tipo de datos de carácter distinto a CLOB, o un tipo de datos gráficos distinto a DBCLOB.
Un tipo de datos de entero binario, un tipo de datos de carácter distinto a CLOB, o un tipo de datos gráficos distinto a DBCLOB se puede convertir a BOOLEAN.
Un argumento sin tipo puede convertirse a cualquier tipo de datos.

Al igual que la lista de prioridades de tipos de datos en el caso de la promoción, para la conversión implícita existe un orden para los tipos de datos que están en el grupo de tipos de datos relacionados. Este orden se utiliza cuando se realiza una resolución de funciones que tiene en cuenta la conversión implícita. La Tabla 1 muestra el orden de los tipos de datos para la conversión implícita para la resolución de funciones. Los tipos de datos se listan en orden de mejor a peor (tenga en cuenta que es diferente del orden de la lista de prioridades de tipos de datos para promoción). En una base de datos Unicode, cuando la resolución de funciones selecciona una función incorporada del esquema SYSIBM y es necesaria una conversión implícita para algún argumento, si la función incorporada da soporte tanto a la entrada de caracteres como de gráficos para el parámetro, el argumento se convierte de forma implícita en un carácter.

Tabla 1. Orden de los tipos de datos para la conversión implícita para resolución de funciones
Grupo de tipos de datos	Lista de tipos de datos para la conversión implícita para resolución de funciones (en orden de mejor a peor)
Tipos de datos numéricos	DECFLOAT, doble, real, decimal, BIGINT, INTEGER, SMALLINT
Tipos de datos de serie de caracteres y gráfica	VARCHAR o VARGRAPHIC, CHAR o GRAPHIC, CLOB o DBCLOB
Tipos de datos de serie binaria	VARBINARY, BINARY, BLOB
Tipos de datos de fecha y hora	TIMESTAMP, DATE

Notas:

Los tipos en minúsculas de la tabla anterior se definen de la forma siguiente:
- decimal = DECIMAL (p,s) o NUMERIC(p,s)
- real = REAL o FLOAT(n) donde n no puede ser superior a 24
- doble = DOUBLE, DOUBLE-PRECISION, FLOAT o FLOAT(n), donde n es mayor que 24
Los sinónimos, más cortos o más lagos, de los tipos de datos listados se consideran iguales a la forma listada.
Sólo en el caso de una base de datos Unicode, los siguientes se consideran tipos de datos equivalentes:
- CHAR o GRAPHIC
- VARCHAR y VARGRAPHIC
- CLOB y DBCLOB

Tabla 2. Longitud derivada de un argumento al invocar una función escalar incorporada del esquema SYSIBM en los casos en que se necesita la conversión implícita
Tipo de datos fuente	Tipo y longitud de destino
	CHAR	GRAPHIC	VARCHAR	VARGRAPHIC	CLOB	DBCLOB	BINARY	VARBINARY	BLOB	TIMESTAMP	DECFLOAT	BOOLEAN
UNTYPED	127	127	254	254	32767	32767	-	-	32767	12	34	5
SMALLINT	6	6	6	6	-	-	-	-	-	-	-	5
INTEGER	11	11	11	11	-	-	-	-	-	-	-	5
BIGINT	20	20	20	20	-	-	-	-	-	-	-	5
DECIMAL (`p`,`s`)	2 +`p`	2 +`p`	2 +`p`	2 +`p`	-	-	-	-	-	-	-	-
REAL	24	24	24	24	-	-	-	-	-	-	-	-
DOUBLE	24	24	24	24	-	-	-	-	-	-	-	-
DECFLOAT	42	42	42	42	-	-	-	-	-	-	-	-
CHAR (`n`)	-	-	-	-	-	-	`n`	`n`	`n`	12	34	-
VAR CHAR (`n`)	min (`n`, 254)	min (`n`, 127)	-	-	-	-	min (`n`, 254)	`n`	`n`	12	34	-
CLOB (`n`)	min (`n`, 254)	min (`n`, 127)	min (`n`, 32672)	min (`n`, 16336)	-	-	-	-	-	-	-	-
GRÁFICO (`n`)	-	-	-	-	-	-	-	-	-	12	34	-
VARGRAPHIC (`n`)	min (`n`, 254)	min (`n`, 127)	-	-	-	-	-	-	-	12	34	-
DBCLOB (`n`)	min (`n`, 254)	min (`n`, 127)	min (`n`, 32672)	min (`n`, 16336)	-	-	-	-	-	-	-	-
BINARY (`n`)	`n`	-	`n`	-	-	-	-	-	-	-	-	-
VARBINARY (`n`)	min (`n`, 254)	-	`n`	-	-	-	min (`n`, 254)	-	-	-	-	-
BLOB (`n`)	min (`n`, 254)	-	min (`n`, 32672)	-	-	-	min (`n`, 254)	min (`n`, 32672)	-	-	-	-
HORA	8	8	8	8	-	-	-	-	-	-	-	-
FECHA	10	10	10	10	-	-	-	-	-	-	-	-
TIMESTAMP (`p`)	si `p`=0 entonces 19 `p`+20	si `p`=0 entonces 19 `p`+20	si `p`=0 entonces 19 `p`+20	si `p`=0 entonces 19 `p`+20	-	-	-	-	-	-	-	-
BOOLEAN	5	5	5	5	-	-	-	-	-	-	-	-
Nota: Esta tabla muestra los tipos de datos de serie de caracteres y de serie gráfica en unidades de serie asociadas a un entorno de base de datos Unicode donde el valor predeterminado de las unidades de serie es SYSTEM. Si el entorno de la base de datos Unicode tiene las unidades de secuencia establecidas en CODEUNITS32, entonces cualquier secuencia de caracteres o atributos de longitud de la secuencia gráfica que representan la longitud máxima del tipo de datos se debe considerar para representar el máximo del tipo de datos en CODEUNITS32. Todas las secuencias de caracteres o tipos de datos de secuencia gráfica tienen unidades de secuencia por omisión del entorno de base de datos.

Consideraciones sobre las vías de acceso SQL para funciones incorporadas

La resolución de funciones se aplica a todas las funciones, incluidas las funciones de esquema y de módulos de tipo incorporadas o definidas por el usuario. Si se invoca una función sin su nombre de esquema, se utiliza la vía de acceso de SQL para resolver la invocación a una función determinada.

Las funciones incorporadas del esquema SYSIBM siempre se tienen en cuenta durante la resolución de las funciones, incluso en el caso de que SYSIBM no se haya incluido de forma explícita en la vía de acceso de SQL. Si se omite SYSIBM de los resultados de vía de acceso se presupone (para la resolución de las funciones y los tipos de datos) que SYSIBM es el primer esquema de la vía de acceso.

Por ejemplo, si la vía de acceso de SQL de un usuario está definida de la siguiente manera:

"SHAREFUN","SYSIBM","SYSFUN"

y hay una función LENGTH definida en el esquema SHAREFUN con el mismo número y los mismos tipos de argumentos que SYSIBM.LENGTH, una referencia no calificada a LENGTH en la sentencia de SQL de este usuario hará que se seleccione SHAREFUN.LENGTH. No obstante, si la vía de acceso de SQL del usuario está definida de la siguiente forma:

"SHAREFUN","SYSFUN"

y existe la misma función SHAREFUN.LENGTH, una referencia no calificada a LENGTH en la sentencia de SQL de este usuario hará que se seleccione SYSIBM.LENGTH, ya que SYSIBM aparece implícitamente antes en la vía de acceso.

Para minimizar los posibles problemas en este aspecto:

No utilice nunca los nombres de funciones incorporadas para funciones definidas por el usuario.
Si, por algún motivo, es necesario crear una función definida por el usuario con el mismo nombre que una función incorporada, asegúrese de calificar todas las referencias a la misma.

Nota: Algunas invocaciones de funciones incorporadas no dan soporte a SYSIBM como calificador explícito y se resuelven directamente en la función incorporada sin tener en cuenta la vía de acceso de SQL. En la descripción de la función incorporada se tratan casos específicos.

Ejemplos de resolución de funciones

Los siguientes son ejemplo de resolución de funciones. (Observe que no se muestran todas las palabras clave necesarias.)

Este es un ejemplo que ilustra las consideraciones sobre vías de acceso SQL en la resolución de funciones. Para este ejemplo, existen ocho funciones ACT, en tres esquemas distintos, registrados como:
```
CREATE FUNCTION AUGUSTUS.ACT (CHAR(5), INT, DOUBLE) SPECIFIC ACT_1 ...
CREATE FUNCTION AUGUSTUS.ACT (INT, INT, DOUBLE) SPECIFIC ACT_2 ...
CREATE FUNCTION AUGUSTUS.ACT (INT, INT, DOUBLE, INT) SPECIFIC ACT_3 ...
CREATE FUNCTION JULIUS.ACT (INT, DOUBLE, DOUBLE) SPECIFIC ACT_4 ...
CREATE FUNCTION JULIUS.ACT (INT, INT, DOUBLE) SPECIFIC ACT_5 ...
CREATE FUNCTION JULIUS.ACT (SMALLINT, INT, DOUBLE) SPECIFIC ACT_6 ...
CREATE FUNCTION JULIUS.ACT (INT, INT, DECFLOAT) SPECIFIC ACT_7 ...
CREATE FUNCTION NERO.ACT (INT, INT, DEC(7,2)) SPECIFIC ACT_8 ...
```
La referencia de función es la siguiente (donde I1 e I2 son columnas INTEGER y D es una columna DECIMAL):
```
SELECT ... ACT(I1, I2, D) ...
```
Suponga que la aplicación que efectúa esta referencia tiene una vía de acceso de SQL establecida como:
```
"JULIUS","AUGUSTUS","CAESAR"
```
De acuerdo con el algoritmo...
- La función que tiene el nombre específico ACT_8 se elimina como candidata, ya que el esquema NERO no se ha incluido en la vía de acceso de SQL.
- La función con el nombre específico ACT_3 se elimina como candidato, porque tiene el número incorrecto de parámetros. ACT_1 y ACT_6 se eliminan porque, en ambos casos, el primer argumento no se puede promocionar al tipo de datos del primer parámetro.
- Como sigue habiendo más de un candidato, los argumentos se tienen en cuenta siguiendo un orden.
- Para el primer argumento, las funciones restantes, ACT_2, ACT_4 y ACT_5 y ACT_7 coinciden exactamente con el tipo de argumento. No se puede pasar por alto ninguna de las funciones; así pues, se debe examinar el argumento siguiente.
- Para este segundo argumento, ACT_2, ACT_5 y ACT_7 son coincidencias exactas pero ACT_4 no lo es, por lo cual se descarta. Se examina el siguiente argumento para determinar alguna diferencia entre ACT_2, ACT_5 y ACT_7.
- Para el tercer y último argumento, ni ACT_2 ni ACT_5 ni ACT_7 coinciden exactamente con el tipo de argumento. Aunque ACT_2 y ACT_5 son igualmente buenos, ACT_7 no es tan bueno como los otros dos ya que el tipo DOUBLE está más próximo a DECIMAL que DECFLOAT. ACT_7 se elimina..
- Quedan dos funciones, ACT_2 y ACT_5, con signaturas de parámetros idénticas. La criba final consiste en determinar el esquema de qué función aparece primero en la vía de acceso de SQL y, en base a ello, se elige ACT_5.
A continuación se muestra un ejemplo de una situación en la que la resolución de funciones generará un error (SQLSTATE 428F5), ya que más de una función candidata es igual de apropiada, pero los parámetros correspondientes para uno de los argumentos no pertenecen a la misma lista de prioridades de tipos.
En este ejemplo, sólo hay tres funciones en un sólo esquema definido de la misma manera:
```
CREATE FUNCTION CAESAR.ACT (INT, VARCHAR(5), VARCHAR(5))SPECIFIC ACT_1 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DATE)     SPECIFIC ACT_2 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)   SPECIFIC ACT_3 ...
```
La referencia de función es la siguiente (donde I1 e I2 son columnas INTEGER y VC es una columna VARCHAR):
```
SELECT ... ACT(I1, I2, VC) ...
```
Suponga que la aplicación que efectúa esta referencia tiene una vía de acceso de SQL establecida como:
```
"CAESAR"
```
De acuerdo con el algoritmo...
- Cada una de las funciones candidatas se evalúa para determinar si el tipo de datos de cada argumento de entrada de la invocación de la función coincide con el tipo de datos del parámetro correspondiente de la instancia de la función o se puede promocionar a éste:
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, ACT_1 se elimina porque INTEGER no se promociona a VARCHAR.
  - Para el tercer argumento, tanto ACT_2 como ACT_3 se eliminan, porque VARCHAR no se puede promocionar a DATE o DOUBLE, por lo que no queda ninguna función candidata.
- Puesto que el subconjunto de funciones candidatas está vacío, las funciones candidatas se toman en consideración utilizando el proceso convertible:
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, ACT_1 se elimina puesto que INTEGER no se promociona a VARCHAR. ACT_2 y ACT_3 son mejores candidatas.
  - Para el tercer argumento, el tipo de datos de los parámetros correspondientes de ACT_2 y ACT_3 no pertenecen a la misma lista de prioridades de tipos de datos, por lo que se ha devuelto un error (SQLSTATE 428F5).
En este ejemplo se ilustra una situación en la que la resolución de funciones será satisfactoria si se utiliza el proceso convertible. En este ejemplo, sólo hay tres funciones en un sólo esquema definido de la misma manera:
```
CREATE FUNCTION CAESAR.ACT (INT, VARCHAR(5), VARCHAR(5))SPECIFIC ACT_1 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DECFLOAT)     SPECIFIC ACT_2 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)   SPECIFIC ACT_3 ...
```
La referencia de función es la siguiente (donde I1 e I2 son columnas INTEGER y VC es una columna VARCHAR):
```
SELECT ... ACT(I1, I2, VC) ...
```
Suponga que la aplicación que efectúa esta referencia tiene una vía de acceso de SQL establecida como:
```
"CAESAR"
```
De acuerdo con el algoritmo...
- Cada una de las funciones candidatas se evalúa para determinar si el tipo de datos de cada argumento de entrada de la invocación de la función coincide con el tipo de datos del parámetro correspondiente de la instancia de la función o se puede promocionar a éste:
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, ACT_1 se elimina porque INTEGER no se promociona a VARCHAR.
  - Para el tercer argumento, tanto ACT_2 como ACT_3 se eliminan, porque VARCHAR no se puede promocionar a DECFLOAT o DOUBLE, por lo que no queda ninguna función candidata.
- Puesto que el subconjunto de funciones candidatas está vacío, las funciones candidatas se toman en consideración utilizando el proceso convertible:
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, ACT_1 se elimina puesto que INTEGER no se promociona a VARCHAR. ACT_2 y ACT_3 son mejores candidatas.
  - Para el tercer argumento, tanto DECFLOAT como DOUBLE están en la misma lista de prioridades de tipos de datos y VARCHAR puede convertirse de forma implícita tanto en DECFLOAT como en DOUBLE. Puesto que DECFLOAT es más apropiada para la conversión implícita, ACT_2 es la candidata más apropiada.
En este ejemplo se muestra cómo, durante la resolución de funciones mediante el proceso convertible, la promoción de los argumentos anteriores tiene prioridad sobre la conversión implícita. En este ejemplo, sólo hay tres funciones en un sólo esquema definido de la misma manera:
```
CREATE FUNCTION CAESAR.ACT (INT, INT, VARCHAR(5))SPECIFIC ACT_1 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DECFLOAT) SPECIFIC ACT_2 ...
CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)  SPECIFIC ACT_3 ...
```
La referencia de función es como se indica a continuación (donde I1 es una columna INTEGER y VC1 es una columna VARCHAR y C1 es una columna CHAR):
```
SELECT ... ACT(I1, VC1, C1) ...
```
Suponga que la aplicación que efectúa esta referencia tiene una vía de acceso de SQL establecida como:
```
"CAESAR"
```
De acuerdo con el algoritmo:
- Cada una de las funciones candidatas se evalúa para determinar si el tipo de datos de cada argumento de entrada de la invocación de la función coincide con el tipo de datos del parámetro correspondiente de la instancia de la función o se puede promocionar a éste:
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, todas las funciones candidatas se eliminan, porque VARCHAR no puede promocionarse a INTEGER, por lo que no queda ninguna función candidata.
- Puesto que el subconjunto de funciones candidatas está vacío, las funciones candidatas se toman en consideración utilizando el proceso convertible
  - Para el primer argumento, todas las funciones candidatas tienen una coincidencia exacta con el tipo de parámetro.
  - Para el segundo argumento, ninguna de las funciones candidatas tiene un parámetro al que el argumento correspondiente pueda promocionarse, por lo que no se elimina ninguna función candidata.
  - Puesto que el tercer argumento puede promocionarse al parámetro de ACT_1, pero no a los parámetros de ACT_2 o ACT_3, ACT_1 es la más apropiada.