[
https://issues.apache.org/jira/browse/CALCITE-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306033#comment-17306033
]
Vladimir Sitnikov commented on CALCITE-4531:
--------------------------------------------
Just in case, JDBC4.2 (1.8+) has {{java.sql.Statement#setLargeMaxRows(long)}}
API.
Even though it is not very practical to return 2^50 rows to the client, I would
expect that Calcite either supports those limits or throws a relevant exception.
intValueExact() does exactly that: it throws an exception if the actual value
does not fit into int.
However, there are lots of cases where the exact value is not needed. For
instance, RelMdRowCount returns Double, so {{RexLiteral.intValue}} is more like
an error since it leaks truncated value which might cause wrong data.
That is why I think intValue is prone to errors in its current implementation.
> 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)
