Class OrderingCoercion
GREATEST and LEAST order arguments that are not already the same family. They
do not merely compare — they CONVERT, and the account's answers say which way:
GREATEST(n, '5') 5 the string joins the number, whichever side it is on
GREATEST('5', n) 5 — still INTEGER, not the first argument's VARCHAR
GREATEST(d, '2027-01-01') 2027-01-01 a date the same way, both orders
GREATEST(bo, n) TRUE BOOLEAN wins over NUMBER, whichever side it is on
GREATEST(v, n) 1 a scalar VARIANT unwraps to its value
GREATEST(n, 2.5) 2.5 two numerics compare by VALUE, not by Java class
GREATEST(n, s) "Numeric value 'abc' is not recognized" — a ROW-time value error
The string rule is the set operation's rule, and it is literally the same code
(SetOperations.coerceStringToLeadingType(java.lang.Object, java.lang.String)) so the two surfaces cannot drift: a string beside
another family converts to that family, and a conversion that fails carries the account's own
sentence rather than a Java one.
What CANNOT be brought together — a BINARY beside anything else — is signalled with
IncomparableArgumentsException instead of being guessed at. The refusal the account gives
there names the operand and its DECLARED type, which only the expression tree knows, so the
evaluator re-asks the static channel for the wording. Comparing them as text, the way an ORDER BY
comparator would, is exactly the leniency this replaced.
-
Method Summary
-
Method Details
-
coerceAll
Every argument converted to the family they will be ordered in — which is also the family of the ANSWER. Live returns the CONVERTED value, not the winning argument as it was written:GREATEST(n, '5')answers the NUMBER 5, not the string, andGREATEST(n, bo)answers TRUE rather than the 1 that outranked nothing. Converting first and ordering after is what makes those two agree.- Parameters:
args- the call's arguments, nulls included- Returns:
- a list of the same size, each value in the common family
-