Conversión de tipos de Postgresql

SQL es un lenguaje fuertemente tipado. Es decir, cada elemento de datos tiene un tipo de datos asociado que determina su comportamiento y uso permitido. PostgreSQL tiene un sistema de tipos extensible que es más general y flexible que otras implementaciones de SQL. Por lo tanto, la mayor parte del comportamiento de conversión de tipos en PostgreSQL se rige por reglas generales en lugar de por ad hoc heurísticas. Esto permite el uso de mixedExpresiones de tipo incluso con tipos definidos por el usuario.

El analizador/analizador de PostgreSQL divide los elementos léxicos en cinco categorías fundamentales: números enteros, números no enteros, cadenas, identificadores y key palabras. Las constantes de la mayoría de los tipos no numéricos se clasifican primero como cadenas. La definición del lenguaje SQL permite especificar nombres de tipo con cadenas, y este mecanismo se puede usar en PostgreSQL para iniciar el analizador en la ruta correcta. Por ejemplo, la consulta:

SELECT text 'Origin' AS "label", point '(0,0)' AS "value";

 label  | value
--------+-------
 Origin | (0,0)
(1 row)

tiene dos constantes literales, de tipo text y point. Si no se especifica un tipo para un string literal, entonces el tipo de marcador de posición unknown se asigna inicialmente, para ser resuelto en etapas posteriores como se describe a continuación.

Hay cuatro construcciones SQL fundamentales que requieren reglas de conversión de tipo distintas en el analizador de PostgreSQL:

Llamadas de función

Gran parte del sistema de tipos de PostgreSQL se basa en un amplio conjunto de funciones. Las funciones pueden tener uno o más argumentos. Dado que PostgreSQL permite la sobrecarga de funciones, el nombre de la función por sí solo no identifica de manera única la función a llamar; el analizador debe seleccionar la función correcta en función de los tipos de datos de los argumentos proporcionados.

Operadores

PostgreSQL permite expresiones con prefix y postfijo operadores unarios (un argumento), así como operadores binarios (dos argumentos). Al igual que las funciones, los operadores pueden sobrecargarse, por lo que existe el mismo problema de seleccionar el operador correcto.

Almacenamiento de valor

sql INSERT y UPDATE Las sentencias colocan los resultados de las expresiones en una tabla. Las expresiones de la declaración deben coincidir con los tipos de las columnas de destino y quizás convertirse a ellos.

UNION, CASEy construcciones relacionadas

Dado que todas las consultas resultan de un sindicato SELECT declaración debe aparecer en un solo conjunto de columnas, los tipos de los resultados de cada SELECT La cláusula debe emparejarse y convertirse en un conjunto uniforme. De manera similar, las expresiones de resultado de un CASE La construcción debe convertirse a un tipo común para que la CASE expresión como un todo tiene un tipo de salida conocido. Algunas otras construcciones, como ARRAY[] y el GREATEST y LEAST funciones, también requieren la determinación de un tipo común para varias subexpresiones.

Los catálogos del sistema almacenan información sobre qué conversiones o yesos, existen entre qué tipos de datos y cómo realizar esas conversiones. El usuario puede agregar moldes adicionales con el comando CREATE CAST. (Esto generalmente se hace junto con la definición de nuevos tipos de datos. El conjunto de conversiones entre los tipos integrados se ha diseñado cuidadosamente y es mejor no modificarlo).

Una heurística adicional proporcionada por el analizador permite una mejor determinación del comportamiento de conversión adecuado entre grupos de tipos que tienen conversiones implícitas. Los tipos de datos se dividen en varios tipos básicos categorías de tipoincluyendo boolean, numeric, string, bitstring, datetime, timespan, geometric, networky definido por el usuario. (Para obtener una lista, consulte la Tabla 51.63; pero tenga en cuenta que también es posible crear categorías de tipos personalizadas). Dentro de cada categoría puede haber una o más tipos preferidos, que se prefieren cuando hay una selección de tipos posibles. Con una selección cuidadosa de los tipos preferidos y las conversiones implícitas disponibles, es posible garantizar que las expresiones ambiguas (aquellas con múltiples soluciones de análisis candidatas) se puedan resolver de manera útil.

Todas las reglas de conversión de tipos están diseñadas teniendo en cuenta varios principios:

• Las conversiones implícitas nunca deben tener resultados sorprendentes o impredecibles.

• No debería haber sobrecarga adicional en el analizador o ejecutor si una consulta no necesita una conversión de tipo implícita. Es decir, si una consulta está bien formada y los tipos ya coinciden, entonces la consulta debería ejecutarse sin gastar más tiempo en el analizador y sin introducir llamadas de conversión implícitas innecesarias en la consulta.

• Además, si una consulta generalmente requiere una conversión implícita para una función, y si luego el usuario define una nueva función con los tipos de argumento correctos, el analizador debe usar esta nueva función y no hacer más una conversión implícita para usar la función anterior.