> On 2011-06-14 19:14:04, John Sichi wrote: > > Wouldn't it be better to change COALESCE to just check that the two objects > > have the same type family (both numeric)? That's what happens in standard > > SQL, and then the widest type is used for the result. This is what UNION > > ALL should be doing also, although currently it uses the same annoying > > check as COALESCE. > >
Also, CAST(0 AS BIGINT) already works the same as 0L. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/889/#review834 ----------------------------------------------------------- On 2011-06-14 19:04:53, Syed Albiz wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/889/ > ----------------------------------------------------------- > > (Updated 2011-06-14 19:04:53) > > > Review request for hive and John Sichi. > > > Summary > ------- > > Added a rule to the lexical grammar to allow BIGINT constants ending with > 'L', and a clause to the TypeCheckProcFactory to ensure it gets interpreted > properly. > > > This addresses bug HIVE-872. > https://issues.apache.org/jira/browse/HIVE-872 > > > Diffs > ----- > > ql/src/java/org/apache/hadoop/hive/ql/parse/Hive.g 9161319 > ql/src/java/org/apache/hadoop/hive/ql/parse/TypeCheckProcFactory.java > dfadb9f > ql/src/test/queries/clientpositive/bigint_const.q PRE-CREATION > ql/src/test/results/clientpositive/bigint_const.q.out PRE-CREATION > > Diff: https://reviews.apache.org/r/889/diff > > > Testing > ------- > > TestCliDriver passes, previous behaviour was to accept bigint constants > specified without 'L', which is also preserved, so adding additional tests > for this case seems unnecessary. > > > Thanks, > > Syed > >
