Doesn’t the patch in question do the reverse? I think we can have a follow-up JIRA if it’s not already done in all circumstances, without the patch.
On 16/6/14, 16:13, "Ashutosh Chauhan" <ashutosh.chau...@gmail.com> wrote: >What about my suggestions to treat non-integral constant literals as >BigDecimal instead of Double? I checked on other products and thats what >MySQL, Oracle & SQL server is doing. > >Thanks, >Ashutosh > >On Tue, Jun 14, 2016 at 4:07 PM, Alan Gates <alanfga...@gmail.com> wrote: > >> I’m +1 on reverting it. Let’s not change around functionality on our >> users and let’s stay as close as possible to the standard, both of which >> reverting this seems to do. >> >> Alan. >> >> > On Jun 10, 2016, at 16:07, Sergey Shelukhin <ser...@hortonworks.com> >> wrote: >> > >> > There has recently been a change in behavior in Hive wrt doubles and >> > decimals, HIVE-13380; where the literals were changed to be double by >> > default, resulting in some unexpected behavior when comparing decimal >> > columns with arithmetic expressions on literals. >> > Right now it has been reverted from 2.1, it’s still there on master >>until >> > we decide what to do. >> > >> > According to SQL92 (I don’t have access to a later one), section 5.3 >> > <exact numeric literal> ::= <unsigned integer> [ <period> [ <unsigned >> > integer> ] ] | <period> <unsigned integer> >> > ... >> > 13)The data type of an <exact numeric literal> is exact numeric. >> > >> > From previous comments there, exact-numeric would basically be >>decimal in >> > this case. >> > >> > Approximate (basically, float/double in this case) literal is defined >>as >> > <approximate numeric literal> ::= <mantissa> E <exponent> >> > >> > Then, in 6.12, the expression (at least the arithmetic) on two exacts >> > needs to have the exact results; if either side is approximate, the >> result >> > is approximate. >> > >> > However, some RDBMS-es apparently prefer double over decimal. >> > >> > I think we should go according to SQL92, revert the patch also from >> > master, and also potentially investigate ANSI SQL compatibility for >> > existing type resolution in other places. >> > Opinions, suggestions, comments? >> > >> > >> > >> > >> >>
