Существует только один оператор извлечения квадратного корня (префиксный |/) определен в стандартном каталоге и принимает аргумент типа данных double precision. Сканер назначает начальный тип данных integer для аргумента в данном выражении запроса:

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

Таким образом, парсер выполняет приведение типов для операнда, и запрос становится эквивалентен:

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

Строковый синтаксис используется как для работы со строковыми типами данных, так и для работы со сложными типами расширений. Строковые литералы с неуказанным типом сопоставляются с наиболее подходящими операторами-кандидатами.

Пример с одним аргументом неизвестного типа:

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

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

В данном случае парсер проверяет, существует ли оператор, принимающий text для обоих аргументов. Так как он существует, предполагается, что второй аргумент должен быть интерпретирован как тип данных text.

Ниже приведен пример конкатенации двух значений неопределенных типов:

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

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

В данном случае нет исходной подсказки о том, какой тип данных использовать, так как в запросе типы не указаны. Поэтому парсер ищет все подходящие операторы и находит кандидатов, принимающих входные данные как строковой категории, так и категории битовых строк. Так как строковая категория является предпочтительной, выбирается именно она, а затем предпочтительный тип данных для строк, text, используется в качестве конкретного типа для разрешения литералов неизвестного типа.

Компонент Digital Q.DataBase каталог операторов содержит несколько записей для префиксного оператора @, все из которых реализуют операции вычисления модуля для различных числовых типов данных. Одна из этих записей предназначена для типа данных float8, который является предпочтительным типом в числовой категории. Следовательно, Digital Q.DataBase будет использовать эту запись при наличии unknown входные данные:

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

В данном случае система неявно разрешила литерал неизвестного типа как тип данных float8 перед применением выбранного оператора. Мы можем убедиться в том, что float8 использовался именно этот, а не какой-либо другой тип данных:

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

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

С другой стороны, префиксный оператор ~ (побитовое отрицание) определен только для целочисленных типов данных, но не для float8. Следовательно, если мы рассмотрим аналогичный случай с ~, то получим:

SELECT ~ '20' AS "negation";

ERROR:  operator is not unique: ~ "unknown"
HINT:  Could not choose a best candidate operator. Возможно, вам потребуется добавить явный оператор CAST.

Это происходит потому, что система не может выбрать один из нескольких возможных ~ следует отдавать предпочтение операторам. Эту ситуацию можно разрешить с помощью явного приведения типов:

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

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

Вот еще один пример разрешения типов для оператора с одним известным и одним неизвестным аргументом:

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

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

Компонент Digital Q.DataBase каталог операторов содержит несколько записей для инфиксного оператора <@, но только две из них могут принимать массив integer с левой стороны: это операторы включения массива (anyarray <@ anyarray) и включения в диапазон (anyelement <@ anyrange). Поскольку ни один из этих полиморфных псевдотипов (см. Раздел 2.5.21) не является предпочтительным, парсер не может разрешить неоднозначность на этом основании. Тем не менее Шаг 3.f позволяет ему предположить, что литерал неизвестного типа имеет тот же тип данных, что и второй аргумент, а именно массив integer. Теперь только один из двух операторов может соответствовать условию, поэтому выбирается оператор включения массивов. (Если бы был выбран механизм включения диапазонов, возникла бы ошибка, так как строка не имеет корректного формата для литерала диапазона.)

Пользователи иногда пытаются объявить операторы, применяемые только к типу-домену. Это возможно, но далеко не так полезно, как может показаться, поскольку правила разрешения операторов разработаны для выбора операторов, применяемых к базовому типу данных домена. В качестве примера рассмотрим

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';

Данный запрос не будет использовать пользовательский оператор. Парсер сначала проверит, существует ли mytext = mytext оператор (Шаг 2.a), которого не существует; тогда будет рассмотрен базовый тип данных домена text, и проверено, существует ли text = text оператор (Шаг 2.b), который существует; таким образом, литерал типа unknownбудет определен как text и будет использован text = text оператор. Единственный способ задействовать пользовательский оператор — явно выполнить приведение типов литерала:

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

чтобы mytext = text оператор был найден сразу согласно правилу точного соответствия. Если применяются правила поиска наилучшего соответствия, они отдают меньший приоритет операторам для типов-доменов. Если бы это было не так, подобные операторы создавали бы слишком много ошибок из-за двусмысленности, поскольку правила приведения типов всегда рассматривают домен как приводимый к своему базовому типу данных или из него, и оператор домена считался бы применимым во всех тех же случаях, что и одноименный оператор для базового типа данных.