Sure. I was just brining that up in the case anyone attempts this approach without understanding that bit of info.
On Sun, Jun 29, 2014 at 10:01 AM, Brian Jeltema < brian.jelt...@digitalenvoy.net> wrote: > Right, but in my case the numbers are never negative. > > On Jun 29, 2014, at 9:52 AM, Edward Capriolo <edlinuxg...@gmail.com> > wrote: > > That does not work if your sorting negative numbers btw. As you would have > to - pad and reverse negative numbers. > > > On Sun, Jun 29, 2014 at 6:35 AM, Brian Jeltema < > brian.jelt...@digitalenvoy.net> wrote: > >> Probably not generally interesting. I needed the numeric value for an >> ‘order by’ clause, so I store the >> value as a string and do "order by lpad(value, 40, ‘0’)” >> >> Brian >> >> On Jun 28, 2014, at 2:51 PM, Lefty Leverenz <leftylever...@gmail.com> >> wrote: >> >> What was your work-around? (If it's generally applicable, we could >> include it in the documentation.) >> >> -- Lefty >> >> >> On Sat, Jun 28, 2014 at 10:08 AM, Brian Jeltema < >> brian.jelt...@digitalenvoy.net> wrote: >> >>> Hive doesn’t support a BigDecimal data type, as far as I know. It >>> supports a Decimal type that >>> is based on BigDecimal, but the precision is limited to 38 digits. >>> >>> However, I found a way to work around the limitation, so it’s no longer >>> an issue for me. >>> >>> Brian >>> >>> On Jun 28, 2014, at 8:22 AM, sumit ghosh <sumi...@yahoo.com> wrote: >>> >>> Did you try BigDecimal? It is the same datatype as Java BigDecimal. >>> >>> >>> On Thursday, 26 June 2014 8:34 AM, Brian Jeltema < >>> brian.jelt...@digitalenvoy.net> wrote: >>> >>> >>> Sorry, I meant 128 bit >>> >>> On Jun 26, 2014, at 11:31 AM, Brian Jeltema < >>> brian.jelt...@digitalenvoy.net> wrote: >>> >>> > I need to represent an unsigned 64-bit value as a Hive DECIMAL. The >>> current precision maximum is 38, >>> > which isn’t large enough to represent the high-end of this value. Is >>> there an alternative? >>> > >>> > Brian >>> > >>> >>> >>> >>> >> >> > >
