The default type system RelDataTypeSystemImpl does not even support 1000 digits
of precision.
In general, if a result needs more digits than available in the type system,
the type inference will prioritize using a higher precision over a higher
scale, since scale specifies "digits after period", which can be rounded with a
smaller relative error.
Mihai
________________________________
From: Sylvain Gaultier
Sent: Wednesday, April 9, 2025 9:33 AM
To: dev@calcite.apache.org
Subject: Re: Behavior on leastRestrictive RelDataType
Sorry, I'm new to Calcite, I'm not very familiar with it.
Where can I find this information?
When I tested the two versions of Calcite, it was in this method that the
behavior changed. :
TypeCoercionImpl.binaryComparisonCoercion(SqlCallBinding)
l243 :
if (kind.belongsTo(SqlKind.BINARY_COMPARISON)) {
final RelDataType commonType = commonTypeForBinaryComparison(type1,
type2);
if (null != commonType) {
coerced = coerceOperandsType(binding.getScope(),
binding.getCall(), commonType);
}
}
"commonType" is now non-null which causes the value 1002.2 to be truncated
to 1002 .
Is it normal that the value is truncated? Is there anything I can do to
prevent this from happening?
On Wed, Apr 9, 2025 at 5:34 PM Mihai Budiu <mbu...@gmail.com> wrote:
> 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.
> >
>
