While the logic is there for aggregation, it is not there for Window Function usage. This will need to be added.

We're adding this as an XML entry, so upgrade will also need to be touched.

Update: since we decided to go always on long double, there is no XML entry.

The logic found in aggregation doesn't work. This will take a bit longer than expected.

The solution is to use long double (80-bit float) for all SUM/AVG calculations. The code has been modified to handle long double everywhere except actual persistence in a table.

If SUM creates a number of magnitude larger than can be held in an int, and then decimal arithmetic is done on the result, an overflow error will occur unless infinidb_double_for_decimal_math is set.

Example:
select s/d from (select b.f3, sum(a.f3) s, count(distinct a.f5) d from aggoverflowa a join aggoverflowb b on a.id=b.id group by 1) s1 order by 1;

Where f3 is INT or DECIMAL in a.

s/d tries to do decimal math. if sum(a.f3) > MAX(long int), a decimal overflow error is thrown.

Creating an automatic overflow here is difficult, since the datatype of the operation is determined in the connector, while the change to long double is determined in ExeMgr – too late to go back.

Since long double is now enabled everywhere, infinidb_double_for_decimal_math now causes long double to be used, allowing for more accuracy, at least on Linux.

Build verified: 1.2.3-1 nightly

server commit:
61f32f2
engine commit:
fddd108

Also performed regression tests.