On 03/12/2013 11:28 AM, Tony Huang wrote:
>
> In 
> src/main/java/com/salesforce/phoenix/expression/DecimalSubtractExpression.java:
>
> >      public DecimalSubtractExpression() {
> >      }
> >
> >      public DecimalSubtractExpression(List<Expression> children) {
> >          super(children);
> > +        maxLengths = new Integer[children.size()];
> I did some experiment with derby and oracle, here is what I find: * 
> Derby would impose precision and rescale on each method, so col1 + 
> col2 + col3, in the case when col1 + col2 does not fit, will result in 
> an exception. * Oracle does not seem to impose any precision or scale 
> on any of the results. The decimal will just keep on growing until it 
> hits a numeric exception. If I declare col1(38), col2(38), and give 
> them maximum value, it would happily returns me col2 + col1 or col1 * 
> col2, which wayy exceeds the precision and scale limit we find.
> … <#>
> On 03/12/2013 10:50 AM, James Taylor wrote: In 
> src/main/java/com/salesforce/phoenix/expression/DecimalSubtractExpression.java: 
> > public DecimalSubtractExpression() { > } > > public 
> DecimalSubtractExpression(List<Expression> children) { > 
> super(children); > + maxLengths = new Integer[children.size()]; I 
> don't see why you can't have an overall precision/scale, calculated 
> using the same logic you've already written, but just as a loop 
> instead of just with the lhs and rhs. It seems better in the case you 
> mentioned if col1 + col2 + col3 doesn't fail if the overall result 
> fits into the overall precision. Were not driving off a spec that says 
> that's not ok. The alternative would be to create arithmetic 
> expressions with only 2 children, instead of n. I just don't see an 
> advantage to failing the expression evaluation in the case you 
> mention. Would Oracle fail it? If Oracle and Postgres and Derby all 
> fail in this case, then let's move to having only 2 children 
> expressions. Otherwise, let's do the above. — Reply to this email 
> directly or view it on GitHub 
> <https://github.com/forcedotcom/phoenix/pull/90/files#r3339744>.
>
> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/forcedotcom/phoenix/pull/90/files#r3340630>.
>
Yeah, it sounds like the spec either doesn't explicitly say what to do 
in these situations, or it's not followed. I think it's best not to 
throw when possible. Let's just roll up the precision and scale to a 
single value for each expression based on the logic you've already 
figured out.