Re: Type system notes

RPost wrote:

> 
> So it appears that the 'result' parameter that SumAggregator's accumulate
> method passes on to the SQLInteger.plus method may 'morph' from a tiny or
> small int to an integer to a long to a big decimal. Thus for this use of
> 'plus' it doesn't appear that the result is necessarily the same class as
> the addend parameters. I may have missed something in the way that
> polymorphism may take care of this.

You are correct, that slipped my mind, even though I was just working on
it. The reason for this is that avg(x) is not a simple as executing
sum(x)/count(x). This is due to overflow, sum(x) on an INT column
returns an INT and thus can throw out of range errors, e.g. imagine just
two rows, each with the value Integer.MAX_VALUE. The sum is out of
range, but the average needs to Integer.MAX_VALUE, thus using SQLInteger
as the summing mechanism doesn't work. Thus the average code uses the
natural type initially for the sum part of average and then moves up to
a type with a greater range if an out of range exception is seen. This
gradual change is for performance, SQLInteger will be faster than
SQLLong or SQLDecimal for addition, especially SQLDecimal will be much
slower.

> 
> There is also a comment by Dan in the AvgAggregator accumulate method:
> 
>   // this code creates data type objects directly, it is anticipating
>   // the time they move into the defined api of the type system. (djd).
> 
> Maybe Dan can comment on what this means.

This is the DataValueFactory issue in those notes, basically it's
assuming that it's ok to new SQLLong (for example) directly without
going through the type factory. Assuming one day that will be the
standard practice for most type implementations. The types package also
used to be split across the impl/iapi groupings.

Dan.