hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashutosh Chauhan <ashutosh.chau...@gmail.com>
Subject Re: [discuss] decimals vs doubles in Hive
Date Tue, 14 Jun 2016 23:13:46 GMT
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 <alanfgates@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 <sergey@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?
> >
> >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message