MCS has two internal subtypes of a DECIMAL: the one fits into int64 and that fits into int128. There is no easy way to promote int64(DECIMAL with 18 digits) into int128(DECIMAL with 38 digits) now.
IMHO we start digging from a wrong direction looking into this particular saturation case. Let's consider a SQL query SELECT d1 FROM cs1 UNION SELECT d2 FROM cs1; where d1 - DECIMAL(38) and d2 - DECIMAL(38,38). MCS knows the types translating query parse tree into the flat runtime program. This translation phase is the time when the saturated precision/scale can be deduced from the given precisions/scales. There are two scenarios from here:
- MCS knows the values distribution for the columns d1 and d2. MCS uses this distribution to calculate the ranges that overlaps the most. This is valid for the simple cases when d1 and d2 are not expressions but columns. Rare case in the real world queries IMHO.
- MCS doesn't know distribution or it is hard to calculate it for the d1, d2 expression columns. MCS here makes a wild guess, let's say integer digits are more important and saturation value becomes DECIMAL(38,0).
This was a short description of one aspect of the problem and there is another one, namely MCS has to notify a user the values were saturated. The simplified design for the second aspect is to add an additional into a PrimitiveJob response PP sends to EM. The structure will have a list of possible warnings/errors with counters that will be propogated back to MDB runtime and to a user eventual.