the result depends on the type system used, in particular the max precision and scale supported
You need to tell us what they are in your case ________________________________ From: Alessandro Solimando <alessandro.solima...@gmail.com> Sent: Wednesday, April 9, 2025 7:58:35 AM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Behavior on leastRestrictive RelDataType Hi Sylvain, assuming the type of "customer.c_acctbal" is "DECIMAL(1000, 0)", I think the rewrite in 1.39 is correct, the result might have changed from 1.37 but I feel that this is due to a bugfix. I have quickly verified with Postgres and it seems to agree on what we do here (that is, truncating the decimal literal). What I can suggest is to write a test and use git bisect to find the commit that changed the behaviour and we see from there. Best regards, Alessandro On Wed, 9 Apr 2025 at 15:24, Sylvain Gaultier <sylvain.gault...@cloud.com.invalid> wrote: > Hi, > Could you please provide me with information on the following behavior? > I'm working with the official 1.39 release. > I have an operation in Calcite that no longer provides the same result (vs. > 1.37). > It's a simple query based on the TPCH model: "SELECT c.c_name FROM customer > c WHERE c.c_acctbal >= 1002.2" > > In TypeCoercionImpl.binaryComparisonCoercion(SqlCallBinding) > , for the comparison "c.c_acctbal >= 1002.2", we have two RelDataTypes > corresponding to the two arguments: DECIMAL(1000,0) and DECIMAL(5.1). > > In the 1.39 version, the > CteTypeFactoryImpl.leastRestrictive(List<RelDataType>) method considers the > least restrictive version to be DECIMAL(1000,0). > So we keep this version and end up with > `C`.`c_acctbal` >= CAST(1002.2 AS DECIMAL(1000, 0)) > > which is not the desired result. > (I saw that there was this ticket CALCITE-6913 since the release but I > don't think that will fix this problem ) > > Thanks for your help. >
