What about my suggestions to treat nonintegral 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, HIVE13380; 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, exactnumeric 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 RDBMSes 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?
> >
> >
> >
> >
>
>
