Existe apenas um operador de raiz quadrada (prefixo |/) definido no catálogo padrão, e recebe um argumento do tipo de dados double precision. O rastreador atribui um tipo de dados inicial integer ao argumento nesta expressão de consulta:

SELECT |/ 40 AS "raiz quadrada de 40";

 raiz quadrada de 40
---------------------
   6.324555320336759
(1 linha)

Assim, o analisador faz uma conversão de tipo de dados no operando, e a consulta fica equivalente a:

SELECT |/ CAST(40 AS double precision) AS "raiz quadrada de 40";

Uma sintaxe semelhante a cadeia de caracteres é usada para trabalhar com tipos de dados de cadeia de caracteres e para trabalhar com tipos de dados de extensão complexos. Cadeias de caracteres com tipo de dados não especificado são correspondidas com prováveis candidatos a operador.

Exemplo com um argumento não especificado:

SELECT text 'abc' || 'def' AS "texto e desconhecido";

 texto e desconhecido
----------------------
 abcdef
(1 linha)

Nesse caso, o analisador analisa se existe um operador aceitando o tipo de dados text para os dois argumentos. Como existe, assume que o segundo argumento deve ser interpretado como sendo do tipo de dados text.

Aqui está uma concatenação de dois valores de tipos de dados não especificados:

SELECT 'abc' || 'def' AS "não especificado";

 não especificado
------------------
 abcdef
(1 linha)

Neste caso, não existe dica inicial para o tipo de dados a ser usado, porque nenhum tipo de dados é especificado na consulta. Assim, o analisador procura todos os operadores candidatos, e descobre haver candidatos aceitando entradas na categoria cadeia de caracteres e na categoria cadeia de bits. Como a categoria cadeia de caracteres é a preferida quando está disponível, essa categoria é selecionada e, em seguida, o tipo de dados preferido para cadeias de caracteres, text, é usado como o tipo de dados específico para resolver os literais com tipo de dados desconhecido.

O catálogo de operadores do PostgreSQL possui várias entradas para o operador de prefixo @, todas implementando operações de valor absoluto para vários tipos de dados numéricos. Uma dessas entradas é para o tipo de dados float8, o tipo de dados preferido na categoria numérica. Portanto, o PostgreSQL usará essa entrada quando for confrontado com uma entrada do tipo de dados unknown:

SELECT @ '-4.5' AS "abs";

 abs
-----
 4.5
(1 linha)

Aqui o sistema resolveu implicitamente o literal de tipo de dados desconhecido como tipo de dados float8 antes de aplicar o operador escolhido. Podemos verificar se foi usado float8, e não algum outro tipo de dados, pela mensagem de erro:

SELECT @ '-4.5e500' AS "abs";
ERRO:  "-4.5e500" está fora do intervalo para o tipo de dados double precision
LINHA 1: SELECT @ '-4.5e500' AS "abs";
                  ^

Por outro lado, o operador de prefixo ~ (negação bit a bit) é definido apenas para os tipos de dados inteiros, e não para float8. Então, se tentarmos um algo semelhante com ~, obteremos:

SELECT ~ '20' AS "negação";
ERRO:  o operador não é único: ~ unknown
LINHA 1: SELECT ~ '20' AS "negação";
                ^
DICA:  Não foi possível escolher o operador que se enquadra melhor.
       Você precisa adicionar conversões de tipo de dados explícitas.

Isso acontece, porque o sistema não pode decidir qual dos vários operadores ~ possíveis deve ser preferido. Podemos ajudar com uma conversão explícita:

SELECT ~ CAST('20' AS int8) AS "negação";

 negação
---------
     -21
(1 linha)

Aqui está outro exemplo de resolução de um operador com uma entrada conhecida e uma desconhecida:

SELECT array[1,2] <@ '{1,2,3}' AS "é subconjunto";

 é subconjunto
---------------
 t
(1 linha)

O catálogo de operadores do PostgreSQL possui várias entradas para o operador infixo <@, mas os únicos dois que podem aceitar uma matriz de inteiros no lado esquerdo são inclusão de matriz (anyarray <@ anyarray) e inclusão de intervalo (anyelement <@ anyrange). Como nenhum destes pseudotipos polimórficos (veja a Seção 8.21) é considerado preferido, o analisador não pode resolver a ambiguidade baseado nisso. No entanto, o Passo 3.f diz para assumir que o literal de tipo de dados desconhecido é do mesmo tipo de dados que a outra entrada, ou seja, uma matriz de inteiros. Agora, apenas um dos dois operadores pode corresponder, portanto, é selecionado inclusão de matriz. (Se tivesse sido selecionado inclusão de intervalo, teríamos recebido um erro, porque a cadeia de caracteres não tem o formato correto para ser um literal de intervalo.)

Às vezes, os usuários tentam declarar operadores que se aplicam apenas a um tipo de dados de domínio. Isto é possível, mas não é tão útil quanto parece, porque as regras de resolução de operadores são projetadas para selecionar operadores que se aplicam ao tipo de dados base do domínio. Como exemplo considere

CREATE DOMAIN mytext AS text CHECK(...);
CREATE FUNCTION mytext_eq_text (mytext, text) RETURNS boolean AS ...;
CREATE OPERATOR = (procedure=mytext_eq_text, leftarg=mytext, rightarg=text);
CREATE TABLE mytable (val mytext);

SELECT * FROM mytable WHERE val = 'foo';

Esta consulta não usará o operador personalizado. O analisador primeiro verá se existe o operador mytext = mytext (Passo 2.a), que não existe; depois irá considerar o tipo de dados base do domínio text, e verificar se existe o operador text = text (Passo 2.b), que existe; então resolve o tipo de dados unknown como text e usa o operador text = text. A única maneira de fazer com que o operador personalizado seja usado é convertendo o literal explicitamente

SELECT * FROM mytable WHERE val = text 'foo';

para que o operador mytext = text seja encontrado imediatamente segundo a regra de correspondência exata. Se as regras de melhor correspondência forem alcançadas, elas discriminarão inteiramente os operadores nos domínios. Caso contrário, tal operador criaria muitas falhas de operador ambíguo, porque as regras de conversão sempre consideram um domínio como sendo passível de conversão de ou para o seu tipo de dados base, portanto o operador de domínio seria considerado utilizável nos mesmos casos onde um operador do tipo de dados base de mesmo nome seria.