В стандартном каталоге определен только один оператор квадратного корня (префиксный |/), который принимает аргумент типа 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, используется в качестве конкретного типа для разрешения неизвестных литералов типа.

Каталог операторов Tantor BE содержит несколько записей для префиксного оператора @, все из которых реализуют операции нахождения абсолютного значения для различных числовых типов данных. Одна из этих записей относится к типу float8, который является предпочтительным типом в категории числовых данных. Поэтому Tantor BE будет использовать эту запись при обработке входных данных типа 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. You might need to add
explicit type casts.

Это происходит потому, что система не может определить, какой из нескольких возможных операторов ~ следует предпочесть. Можно помочь ей с явным приведением типа:

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)

Каталог операторов Tantor BE содержит несколько записей для инфиксного оператора <@, но только две из них могут принимать целочисленный массив в качестве левого операнда: включение массива (anyarray <@ anyarray) и включение диапазона (anyelement <@ anyrange). Поскольку ни один из этих псевдотипов полиморфных типов (см. Раздел 8.21) не считается предпочтительным, парсер не может разрешить неоднозначность на этой основе. Однако Step 3.f указывает парсеру предположить, что литерал неизвестного типа имеет тот же тип, что и другой операнд, то есть целочисленный массив. Теперь только один из двух операторов может соответствовать, поэтому выбрано включение массива. (Если бы было выбрано включение диапазона, мы получили бы ошибку, потому что строка не имеет правильного формата для представления диапазонного литерала).

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

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 (Step 2.a), которого нет; затем он рассмотрит базовый тип домена text и проверит, есть ли оператор text = text (Step 2.b), которого есть; поэтому он разрешает литерал типа unknown как text и использует оператор text = text. Единственный способ использовать пользовательский оператор - явно привести литерал:

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

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