[
https://issues.apache.org/jira/browse/CALCITE-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798376#comment-17798376
]
Mihai Budiu commented on CALCITE-3522:
--------------------------------------
I have changed the title of this issue. We have the following code in
SqlValidatorImpl:
{code}
@Override public void validateLiteral(SqlLiteral literal) {
switch (literal.getTypeName()) {
case DECIMAL:
// Decimal and long have the same precision (as 64-bit integers), so
// the unscaled value of a decimal must fit into a long.
// REVIEW jvs 4-Aug-2004: This should probably be calling over to
// the available calculator implementations to see what they
// support. For now use ESP instead.
//
// jhyde 2006/12/21: I think the limits should be baked into the
// type system, not dependent on the calculator implementation.
BigDecimal bd = literal.getValueAs(BigDecimal.class);
BigInteger unscaled = bd.unscaledValue();
long longValue = unscaled.longValue();
if (!BigInteger.valueOf(longValue).equals(unscaled)) {
// overflow
throw newValidationError(literal,
RESOURCE.numberLiteralOutOfRange(bd.toString()));
}
break;
{code}
This looks wrong. Nothing in the spec says that the precision of Decimals is
limited.
To me it looks like checks can be just removed.
> sql validator limits decimal literals to 64 bits
> ------------------------------------------------
>
> Key: CALCITE-3522
> URL: https://issues.apache.org/jira/browse/CALCITE-3522
> Project: Calcite
> Issue Type: Test
> Components: core
> Affects Versions: 1.18.0
> Reporter: Changbo Shu
> Priority: Minor
> Attachments: code.png
>
>
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2983]
> for example:
> create table tbl(f1 double),
> f1 stores a double's max value. (1.7976931348623157E308)
> long max value is 9223372036854775807.
> select * from table where f1=value, if value is greater than long max,
> sqlvalidator will throw out of range exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
