I see. Thank you for your answers. On Wed, Dec 8, 2021 at 4:41 PM Julian Hyde <[email protected]> wrote:
> 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 > >> > >> > >
