Sorry if i was brief earlier.
In the following statement,
`update t1 set bigint_col = int_col`the type coercion rules in the validator
kick in and decide that a cast is not needed between `bigint_col` and
`int_col`. This is because of the type precedence rules of int columns and
bigint columns (via AbstractTypeCoercion#coerceColumnType and
AbstractTypeCoercion#needToCast)
However, in a statement like`select * from t1 where bigint_col = int_col`
a cast is applied, since the EQUALS operator has a OperandTypeChecker whose
Consistency is LEAST_RESTRICTIVE, which mandates that a cast be applied to the
least restrictive type. This happens during the SqlToRelConversion phase.
What was coming to my mind were 2 things1. Why type coercion is handled in 2
places.
2. Just like in the `select` statement, the code consulted the EQUALS operator
to find out whether a cast was needed or not, should there not be a concept of
a "ASSIGNMENT" operator for INSERT/UPDATE/MERGE that is consulted about the
type coercion rules rather than a piece of code that sits separately
(TypeCoercion)
On Wednesday, 23 October, 2024 at 06:16:19 pm IST, Cancai Cai
<[email protected]> wrote:
+1, Agreed. We need more details.
Best wishes,
Cancai Cai
> 2024年10月23日 20:33,Xiong Duan <[email protected]> 写道:
>
> Hi Abbas, I don't understand what you mean. Can you use an SQL
> statement to express what kind of output you want and What the
> Calcite's output is? Then we will discuss the details.