Description
The merged change is still wrong. The supertype of INT, SMALLINT, and DECIMAL(5, 0), according to #1554 is DECIMAL. Though, when
computeDecimal
is invoked to compute the precision and scale, it throws an error when folding over the types of INT and SMALLINT.
This PR merges the not completely correct code while mitigating the thrown exception. I tried to apply as minimal changes as possible to the merge, but this is one area known to have a bug.
Originally posted by @johnedquinn in #1565 (comment)
In SQL:1999, Section 9.3 (Data types of results of aggregations), it specifies several rules of coercing the branches of a case expression. These rules are not followed. It needs to be fixed.
I would probably look at the recent implementations of the 2D tables for CastTable and DatumComparator -- we can probably implement something quite similar.