Yes, that might work.
> On Dec 8, 2021, at 4:35 PM, Jihoon Son <[email protected]> wrote:
>
> Julian, thanks for your answer.
>
> The case I'm looking into is a function that accepts a numeric and returns
> a numeric such as 'floor(123.0)'. In this case, the literal is created
> using `rexBuilder.makeLiteral(123.0,
> typeFactory.createSqlType(SqlTypeName.INTEGER), true)`. This creates a
> literal that has a RelDataType of integer but has a decimal SqlTypeName. In
> the caller of getValueAs(), I'm using `literal.getType().getSqlTypeName()`
> since it is the real type of the literal as its javadoc says and asking for
> a Long because integers are represented as longs in our app. Are you
> suggesting always asking for BigDecimal when it's an exact numeric type and
> converting it to Long in our app?
>
> On Wed, Dec 8, 2021 at 4:00 PM Julian Hyde <[email protected]> wrote:
>
>> When Calcite generates enumerable code, it represents each SQL DECIMAL
>> value as a scaled Java Long. (Just as it represents SQL DATE values as Java
>> Integer.)
>>
>> If you want that ‘raw’ value, ask for a BigDecimal. That’s how DECIMAL
>> values are stored at prepare time (i.e. inside the RexLiteral).
>>
>> Julian
>>
>>
>>
>>> On Dec 8, 2021, at 3:27 PM, Jihoon Son <[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> I am using the 'RexLiteral.getValueAs()' method to convert a literal to a
>>> java object. I recently noticed that this method returns an unscaled
>> value
>>> when you convert a decimal literal to a Long object. As a result, this
>>> method returns '1230' for the decimal literal of '123.0'. The code piece
>> in
>>> question can be found in
>>>
>> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rex/RexLiteral.java#L1051-L1054
>> .
>>> I checked the git commit associated with this behavior, but could not
>> find
>>> anything from it. I would like to understand this behavior better. Can
>>> someone explain the rationale for this?
>>>
>>> Thanks,
>>> Jihoon
>>
>>
