[
https://issues.apache.org/jira/browse/CALCITE-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306483#comment-17306483
]
Julian Hyde commented on CALCITE-4531:
--------------------------------------
The main bug here is that Calcite's validator should throw if LIMIT or OFFSET
(or LIMIT + OFFSET?) is 2^31 or higher. All the other code has been operating
on that assumption. Also, Sort should check that offset and limit are of SQL
type INTEGER, for people creating RelNodes not by parsing SQL.
And document {{RexLiteral.intValue}}, {{RexLiteral.getValueAs}} and similar
methods to make it clear that they truncate.
If you like, you can log a feature request to change the type from INTEGER to
BIGINT. That would be lower priority.
> Deprecate RexLiteral#intValue since it performs silent truncation
> -----------------------------------------------------------------
>
> Key: CALCITE-4531
> URL: https://issues.apache.org/jira/browse/CALCITE-4531
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Vladimir Sitnikov
> Priority: Critical
>
> {{RexLiteral#intValue}} is prone to errors since it silently truncates values
> to {{int}} so the developers might fail to know that at the compile time.
> It might be safer to expose {{BigDecimal}} or {{intValueExact}} or
> {{doubleValue}} alternatives which would be "enough for all the possible
> cases".
> An alternative option is to mark the method as deprecated, so every use of
> the method would require users to suppress the warning, so they know why the
> method is deprecated.
> I guess the most common use case for {{RexLiteral.intValue}} is {{offset}}
> and {{fetch}} in {{Sort}}, however, the misuse is hard to spot, and it might
> result in hard to notice data corruptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
