[
https://issues.apache.org/jira/browse/DERBY-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173316#comment-13173316
]
Dag H. Wanvik commented on DERBY-5546:
--------------------------------------
I agree about your interpretation of the API comment about precision loss. I
took my cues from the current way this is current handled, cf. the code in
SQLReal#setDouble:
float fv = (float) theValue;
// detect rounding taking place at cast time
if (fv == 0.0f && theValue != 0.0d) {
throw StandardException.newException(
SQLState.LANG_OUTSIDE_RANGE_FOR_DATATYPE, TypeId.REAL_NAME);
}
This is indeed (only) a special case of precision loss. I haven't found any
definitions about what should happen in the JDBC standard, so I guess it's
implementation defined. With my patch the behavior is more consistent. We could
also signal other forms of precision loss, like the one you show, or we could
stop throwing on the above also. What do you think?
> ResultSet#updateBigDecimal on a REAL column does not do underflow checking
> --------------------------------------------------------------------------
>
> Key: DERBY-5546
> URL: https://issues.apache.org/jira/browse/DERBY-5546
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.2.2
> Reporter: Dag H. Wanvik
> Priority: Minor
> Attachments: MissingUnderflowCheck.java, derby-5546.diff,
> derby-5546.stat
>
>
> In contrast, ResultSet#updateBigDecimal on a FLOAT or DOUBLE column gives the
> expected error on underflow. Cf. the attached repro program
> MissingUnderflowCheck.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
