Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.
Check for an exact match in the pg_operator system catalog.
If one argument of a binary operator is unknown,
then assume it is the same type as the other argument.
Reverse the arguments, and look for an exact match with an operator which
points to itself as being commutative.
If found, then reverse the arguments in the parse tree and use this operator.
Look for the best match.
Make a list of all operators of the same name.
If only one operator is in the list, use it if the input type can be coerced,
and throw an error if the type cannot be coerced.
Keep all operators with the most explicit matches for types. Keep all if there
are no explicit matches and move to the next step.
If only one candidate remains, use it if the type can be coerced.
If any input arguments are "unknown", categorize the input candidates as
boolean, numeric, string, geometric, or user-defined. If there is a mix of
categories, or more than one user-defined type, throw an error because
the correct choice cannot be deduced without more clues.
If only one category is present, then assign the "preferred type"
to the input column which had been previously "unknown".
Choose the candidate with the most exact type matches, and which matches
the "preferred type" for each column category from the previous step.
If there is still more than one candidate, or if there are none,
then throw an error.
There is only one exponentiation
operator defined in the catalog, and it takes float8 arguments.
The scanner assigns an initial type of int4 to both arguments
of this query expression:
tgl=> select 2 ^ 3 AS "Exp";
Exp
-----
8
(1 row)
So the parser does a type conversion on both operands and the query
is equivalent to
Note: This last form has the least overhead, since no functions are called to do
implicit type conversion. This is not an issue for small queries, but may
have an impact on the performance of queries involving large tables.
A string-like syntax is used for working with string types as well as for
working with complex extended types.
Strings with unspecified type are matched with likely operator candidates.
One unspecified argument:
tgl=> SELECT text 'abc' || 'def' AS "Text and Unknown";
Text and Unknown
------------------
abcdef
(1 row)
In this case the parser looks to see if there is an operator taking text
for both arguments. Since there is, it assumes that the second argument should
be interpreted as of type text.
In this case there is no initial hint for which type to use, since no types
are specified in the query. So, the parser looks for all candidate operators
and finds that all arguments for all the candidates are string types. It chooses
the "preferred type" for strings, text, for this query.
Note: If a user defines a new type and defines an operator "||" to work
with it, then this query would no longer succeed as written. The parser would
now have candidate types from two categories, and could not decide which to use.
This example illustrates an interesting result. Traditionally, the
factorial operator is defined for integers only. The Postgres
operator catalog has only one entry for factorial, taking an integer operand.
If given a non-integer numeric argument, Postgres
will try to convert that argument to an integer for evaluation of the
factorial.
Note: Of course, this leads to a mathematically suspect result,
since in principle the factorial of a non-integer is not defined.
However, the role of a database is not to teach mathematics, but
to be a tool for data manipulation. If a user chooses to take the
factorial of a floating point number, Postgres
will try to oblige.
