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 <jhyde.apa...@gmail.com> 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 <jihoon...@apache.org> 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 > >
