Expand description
Coercion rules for matching argument types for binary operators
Functions§
- binary_
numeric_ coercion - Coerce
lhs_type
andrhs_type
to a common type where both are numeric - comparison_
coercion - Coerce
lhs_type
andrhs_type
to a common type for the purposes of a comparison operation - comparison_
coercion_ numeric - Similar to
comparison_coercion
but prefers numeric if compares with numeric and string - decimal_
coercion - Decimal coercion rules.
- get_
input_ types - Returns the coerced input types for a binary expression evaluating the
op
with the left and right hand types - get_
result_ type - Returns the resulting type of a binary expression evaluating the
op
with the left and right hand types - get_
wider_ type - Returns the wider type among arguments
lhs
andrhs
. The wider type is the type that can safely represent values from both types without information loss. Returns an Error if types are incompatible. - like_
coercion - Coercion rules for like operations. This is a union of string coercion rules and dictionary coercion rules
- regex_
coercion - Coercion rules for regular expression comparison operations. This is a union of string coercion rules and dictionary coercion rules
- string_
coercion - Coercion rules for string view types (Utf8/LargeUtf8/Utf8View): If at least one argument is a string view, we coerce to string view based on the observation that StringArray to StringViewArray is cheap but not vice versa.
- try_
type_ union_ resolution - Handle type union resolution including struct type and others.
- try_
type_ union_ resolution_ with_ struct - type_
union_ resolution - Coerce dissimilar data types to a single data type. UNION, INTERSECT, EXCEPT, CASE, ARRAY, VALUES, and the GREATEST and LEAST functions are examples that has the similar resolution rules. See https://www.postgresql.org/docs/current/typeconv-union-case.html for more information. The rules in the document provide a clue, but adhering strictly to them doesn’t precisely align with the behavior of Postgres. Therefore, we’ve made slight adjustments to the rules to better match the behavior of both Postgres and DuckDB. For example, we expect adjusted decimal precision and scale when coercing decimal types.