Uma consulta SQL pode, intencionalmente ou não, requerer a utilização de tipos de dado diferentes na mesma expressão. O PostgreSQL possui um grande número de funcionalidades para avaliar expressões mistas.
Em muitos casos o usuário não precisará compreender os detalhes do mecanismo de conversão de tipo. Entretanto, as conversões implícitas feitas pelo PostgreSQL podem afetar o resultado da consulta. Quando for necessário, estes resultados podem ser adequados pelo usuário ou pelo programador utilizando a conversão explícita de tipo.
Este capítulo introduz os mecanismos e as convenções de conversão de tipo de dado do PostgreSQL. Consulte as seções apropriadas no Capítulo 5 e no Capítulo 6 para obter mais informações relativas a tipos de dado específicos e funções e operadores permitidos.
O Guia do Programador do PostgreSQL contém mais detalhes relativos aos algoritmos utilizados para conversão implícita e explícita de tipo.
O SQL é uma linguagem fortemente tipada, ou seja, todo item de dado possui um tipo de dado associado que determina seu comportamento e a utilização permitida. O PostgreSQL possui um sistema de tipo de dado extensível muito mais geral e flexível que outras implementações do SQL. Por isso, o comportamento usual para conversão de tipo no PostgreSQL deve ser governado por regras gerais em vez de heurísticas ad hoc [1] para permitir expressões com tipos mistos terem significado inclusive com tipos definidos pelo usuário.
A leitor/analisador do PostgreSQL decodifica os elementos léxicos em apenas cinco categorias fundamentais: inteiros, números de ponto flutuante, cadeias de caracteres, nomes e palavras chave. Os tipos estendidos são inicialmente colocados em cadeias de caracteres, em sua maioria. A definição da linguagem SQL permite especificar nomes de tipos em cadeias de caracteres, e este mecanismo pode ser utilizado pelo PostgreSQL para colocar o analisador na direção do caminho correto. Por exemplo, a consulta
tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value"; Label | Value --------+------- Origin | (0,0) (1 row)
possui duas constantes literais, dos tipos text e point. Se o tipo não for especificado para o literal cadeia de caracteres, o tipo polivalente unknown é atribuído inicialmente, para ser resolvido posteriormente nos estágios descritos abaixo.
Existem quatro construções fundamentais SQL que requerem regras de conversão de tipo distintas no analisador do PostgreSQL:
O PostgreSQL permite expressões com operadores unários (um só argumento) de prefixo e sufixo, assim como operadores binários (dois argumentos).
Grande parte do sistema de tipo do PostgreSQL é construído em torno de um amplo conjunto de funções. As chamadas de função podem possuir um ou mais argumentos os quais, para uma determinada consulta, devem ser correspondidos por uma das funções disponíveis no catálogo do sistema. Uma vez que o PostgreSQL permite a sobrecarga de funções, apenas o nome da função não identifica unicamente a função a ser chamada; o analisador deve selecionar a função correta baseado nos tipos de dado dos argumentos fornecidos.
Os comandos SQL INSERT e UPDATE colocam os resultados das expressões em tabelas. As expressões no comando devem corresponder, ou talvez serem convertidas, nos tipos de dado das colunas de destino.
Uma vez que os resultados de todos os comandos SELECT da união devem retornar em um único conjunto de colunas, deve haver correspondência entre os tipos de dado do resultado de cada uma das cláusulas SELECT, para se tornar um conjunto uniforme. Do mesmo modo, os resultados das expressões da construção CASE devem ser todos convertidos no mesmo tipo de dado para a expressão CASE ter, como um todo, um tipo de dado de saída conhecido.
Grande parte das regras gerais para conversão de tipo de dado utilizam convenções simples, baseadas nas funções do PostgreSQL e tabelas de operadores do sistema. Existe alguma heurística [2] incluída nas regras de conversão para fornecer um melhor apoio às convenções dos tipos nativos do padrão SQL como smallint, integer e real.
Os catálogos do sistema armazenam informações sobre quais conversões, chamadas de casts, entre os tipos de dado são válidas, e como realizar estas conversões. Outras conversões podem ser adicionadas pelo usuário utilizando o comando CREATE CAST (Geralmente isto é feito juntamente com a definição de novos tipos de dado. O conjunto de conversões entre tipos nativos foi cuidadosamente elaborado, não devendo ser modificado).
Uma heurística adicional é incluída no analisador para permitir estimar melhor o comportamento apropriado para os tipos do padrão SQL. Existem diversas categorias de tipo básicas definidas: boolean, numeric, string, bitstring, datetime, timespan, geometric, network e definido pelo usuário. Cada uma das categorias, com exceção da definida pelo usuário, possui um tipo preferido que é preferencialmente selecionado quando há ambigüidade. Na categoria definido pelo usuário, cada tipo é o seu próprio tipo preferido. As expressões ambíguas (as que possuem muitas soluções candidatas na análise) podem, geralmente, serem resolvidas quando há vários tipos nativos possíveis, mas ocasionam erro quando existem várias escolhas para tipos definidos pelo usuário.
Todas as regras de conversão são elaboradas com vários princípios em mente:
As conversões implícitas nunca devem produzir resultados surpreendentes ou imprevisíveis.
Tipos definidos pelo usuário, para os quais o analisador não possua nenhum conhecimento a priori, devem vir "acima" na hierarquia de tipo. Nas expressões com tipos mistos, os tipos nativos devem sempre ser convertidos para o tipo definido pelo usuário (obviamente, apenas se a conversão for necessária).
Tipos definidos pelo usuário não são relacionados. Atualmente o PostgreSQL não dispõe de informações relativas ao relacionamento entre tipos, além das heurísticas codificadas para os tipos nativos e relacionamentos implícitos baseado nas funções disponíveis no catálogo.
Não deve haver nenhum trabalho adicional do analisador ou do executor se o comando não necessitar de conversão implícita de tipo, ou seja, se o comando estiver bem formulado e os tipos já se correspondem, então o comando deve prosseguir sem perda de tempo do analisador e sem introduzir funções de conversão implícitas desnecessárias no comando.
Além disso, se o comando geralmente requer uma função implícita para conversão de tipo, e o usuário definir uma função explícita com argumentos do tipo correto, o analisador deve usar esta nova função, não fazendo mais a conversão implícita utilizando a função antiga.
| [1] | ad hoc: para isso, para esse caso - Novo Dicionário Aurélio da Língua Portuguesa. (N.T.) |
| [2] | heurística: conjunto de regras e métodos que conduzem à descoberta, à invenção e à resolução de problemas - Novo Dicionário Aurélio da Língua Portuguesa. (N.T.) |