[
https://issues.apache.org/jira/browse/HIVE-13963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-13963:
------------------------------------
Description:
See HIVE-13957.
The default precision and scale for the implicit decimal cast are -max,max, ie
38,38- 38,18. Those don't do what the code may assume they do. All the values
>=1 become invalid and precision-scale enforcement automatically converts them
to null.
We need to
1) Validate when this happens in/after the conversion code and bail;
2) Or, derive precision and scale from the constants themselves so they all
fit, instead;
3) Or, derive it from the type of whatever caused the conversion in the first
place (e.g. IN column decimal); however, this could be function-specific (e.g.
IN just needs equality, BETWEEN would need at least one extra digit,
arithmetic, if this ever happens, would need everything, etc.);
4) Something else? :)
was:
See HIVE-13957.
The default precision and scale for the implicit decimal cast are -max,max, ie
38,38-38,18. Those don't do what the code may assume they do. All the values
>=1 become invalid and precision-scale enforcement automatically converts them
to null.
We need to
1) Validate when this happens in/after the conversion code and bail;
2) Or, derive precision and scale from the constants themselves so they all
fit, instead;
3) Or, derive it from the type of whatever caused the conversion in the first
place (e.g. IN column decimal); however, this could be function-specific (e.g.
IN just needs equality, BETWEEN would need at least one extra digit,
arithmetic, if this ever happens, would need everything, etc.);
4) Something else? :)
> vectorization - string arguments may be converted to decimal null
> -----------------------------------------------------------------
>
> Key: HIVE-13963
> URL: https://issues.apache.org/jira/browse/HIVE-13963
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Matt McCline
>
> See HIVE-13957.
> The default precision and scale for the implicit decimal cast are -max,max,
> ie 38,38- 38,18. Those don't do what the code may assume they do. All the
> values >=1 become invalid and precision-scale enforcement automatically
> converts them to null.
> We need to
> 1) Validate when this happens in/after the conversion code and bail;
> 2) Or, derive precision and scale from the constants themselves so they all
> fit, instead;
> 3) Or, derive it from the type of whatever caused the conversion in the first
> place (e.g. IN column decimal); however, this could be function-specific
> (e.g. IN just needs equality, BETWEEN would need at least one extra digit,
> arithmetic, if this ever happens, would need everything, etc.);
> 4) Something else? :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
