Sólo hay un operador raíz cuadrada (prefijo |/) definido en el catálogo estándar, y toma un argumento de tipo double precision. El escáner asigna un tipo inicial de integer al argumento en esta expresión de consulta:

SELECT |/ 40 AS "square root of 40";
 square root of 40
-------------------
 6.324555320336759
(1 row)

De modo que el analizador realiza una conversión de tipo en el operando y la consulta es equivalente a:

SELECT |/ CAST(40 AS double precision) AS "square root of 40";

Se utiliza una sintaxis similar a la de las cadenas para trabajar con tipos de cadenas y para trabajar con tipos de extensión complejos. Las cadenas con tipo no especificado se emparejan con los candidatos de operador probables.

Un ejemplo con un argumento no especificado:

SELECT text 'abc' || 'def' AS "text and unknown";

 text and unknown
------------------
 abcdef
(1 row)

En este caso, el analizador comprueba si hay un operador que tome text para ambos argumentos. Dado que existe, asume que el segundo argumento debería interpretarse como de tipo text.

Aquí tienes una concatenación de dos valores de tipos no especificados:

SELECT 'abc' || 'def' AS "unspecified";

 unspecified
-------------
 abcdef
(1 row)

En este caso no hay ninguna pista inicial sobre qué tipo usar, ya que no se especifican tipos en la consulta. Por lo tanto, el analizador busca todos los operadores candidatos y descubre que hay candidatos que aceptan tanto entradas de la categoría string como de la categoría bit-string. Dado que la categoría string es preferida cuando está disponible, se selecciona esa categoría, y luego se utiliza el tipo preferido para cadenas, text, como el tipo específico para resolver los literales de tipo desconocido.

El catálogo de operadores de PostgreSQL tiene varias entradas para el operador de prefijo @, todas las cuales implementan operaciones de valor absoluto para varios tipos de datos numéricos. Una de estas entradas es para el tipo float8, que es el tipo preferido en la categoría numérica. Por lo tanto, PostgreSQL utilizará esa entrada cuando se enfrente a una entrada unknown:

SELECT @ '-4.5' AS "abs";
 abs
-----
 4.5
(1 row)

Aquí el sistema ha resuelto implícitamente el literal de tipo desconocido como de tipo float8 antes de aplicar el operador elegido. Podemos verificar que se usó float8 y no algún otro tipo:

SELECT @ '-4.5e500' AS "abs";

ERROR:  "-4.5e500" is out of range for type double precision

Por lo lado, el operador de prefijo ~ (negación a nivel de bits) está definido sólo para tipos de datos enteros, no para float8. Por lo tanto, si intentamos un caso similar con ~, obtenemos:

SELECT ~ '20' AS "negation";

ERROR:  operator is not unique: ~ "unknown"
HINT:  Could not choose a best candidate operator. You might need to add
explicit type casts.

Esto sucede porque el sistema no puede decidir cuál de los varios operadores ~ posibles debería ser preferido. Podemos ayudarle con un cast explícito:

SELECT ~ CAST('20' AS int8) AS "negation";

 negation
----------
      -21
(1 row)

Aquí tienes otro ejemplo de cómo resolver un operador con una entrada conocida y otra desconocida:

SELECT array[1,2] <@ '{1,2,3}' as "is subset";

 is subset
-----------
 t
(1 row)

El catálogo de operadores de PostgreSQL tiene varias entradas para el operador infijo <@, pero las dos únicas que podrían aceptar una matriz de enteros en el lado izquierdo son la inclusión de matrices (anyarray <@ anyarray) y la inclusión de rangos (anyelement <@ anyrange). Dado que ninguno de estos pseudo-tipos polimórficos (consulta Section 8.21) se considera preferido, el analizador no puede resolver la ambigüedad sobre esa base. Sin embargo, el paso Step 3.f le indica que asuma que el literal de tipo desconocido es del mismo tipo que la otra entrada, es decir, una matriz de enteros. Ahora sólo uno de los dos operadores puede coincidir, por lo que se selecciona la inclusión de matrices. (Si se hubiera seleccionado la inclusión de rangos, habríamos obtenido un error, porque la cadena no tiene el formato correcto para ser un literal de rango).

A veces los usuarios intentan declarar operadores que se aplican únicamente a un tipo de dominio. Esto es posible pero no es tan útil como podría parecer, porque las reglas de resolución de operadores están diseñadas para seleccionar operadores que se aplican al tipo base del dominio. Como ejemplo considera

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 no utilizará el operador personalizado. El analizador comprobará primero si hay un operador mytext = mytext (Step 2.a), el cual no existe; luego considerará el tipo base del dominio, text, y comprobará si hay un operador text = text (Step 2.b), el cual sí existe; por lo que resuelve el literal de tipo unknown como text y utiliza el operador text = text. La única forma de conseguir que se utilice el operador personalizado es realizar un cast explícito sobre el literal:

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

de modo que el operador mytext = text se encuentre inmediatamente de acuerdo con la regla de coincidencia exacta. Si se llega a las reglas de mejor coincidencia, estas discriminan activamente los operadores en tipos de dominio. Si no lo hicieran, dicho operador crearía demasiados fallos de operador ambiguo, porque las reglas de casting siempre consideran que un dominio es convertible hacia o desde su tipo base, y por lo tanto el operador del dominio se consideraría utilizable en todos los mismos casos que un operador con nombre similar en el tipo base.