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.

  

Reply via email to