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>.
>