This is a very old issue in Calcite. I hope to be able to merge the fix soon: https://github.com/apache/calcite/pull/3733 However, the fix itself has uncovered a bunch of other issues, so things are not quite so straightforward.
Mihai ________________________________ From: Alessandro Solimando <alessandro.solima...@gmail.com> Sent: Tuesday, June 4, 2024 4:40 AM To: n...@sqreamtech.com.invalid <n...@sqreamtech.com.invalid> Cc: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Casting Decimal literals problem Hi Neo, this is a known issue, you can check CALCITE-6322 <https://issues.apache.org/jira/browse/CALCITE-6322> and related tickets. Best regards, Alessandro On Tue, 4 Jun 2024 at 11:58, Neo Michael <n...@sqreamtech.com.invalid> wrote: > Hello Calcite devs, > I have come across some strange behavior when Decimal literals are being > casted to a different precision and scale. For example for something like: > > : jdbc:calcite:model=src/test/resources/mode> select cast(1.11 as > numeric(3,1)); +--------+ | EXPR$0 | +--------+ | 1.11 | +--------+ 1 row > selected (0.509 seconds) > > Is this not the wrong result? No casting takes place, the actual cast is > removed, the literal is given the new RelDataType of Numeric(3, 1), but the > actual Java BigDecimal is not modified (the java object has precision 3 and > scale 2). Unless I am misunderstanding the semantics of Numeric, 1.11 is > not representable in type Numeric(3,1). This is using Calcite > 1.38.0-SNAPSHOT > > I have seen more issues when repeated casts are removed (deemed > superfluous by the simplifier), but it may be the same issue so let's deal > with this simpler case first. > > Thank you for any help, > Neo >
