1. In TupleAggregateStep::configDeliveredRowGroup(), use
jobInfo.projectionCols instead of jobInfo.nonConstCols
for setting scale and precision if the source column is
wide decimal.
2. Tighten rules for wide decimal processing. Specifically:
a. Replace (precision > INT64MAXPRECISION) checks with
(precision > INT64MAXPRECISION && precision <= INT128MAXPRECISION)
b. At places where (colWidth == MAXDECIMALWIDTH) is not enough to
determine if a column is wide decimal or not, also add a check on
type being DECIMAL/UDECIMAL.
- The code in ha_mcs_partition.cpp erroneously printed data
to a temporary ostringstream "oss" instead of "output".
- The left-side adjustfield (applied when printing the range values)
unintentionally disappeared during MCOL-4174 refactoring.
Restoring left adjustfield in TypeHandler::PrintPartitionValue*().
In addition, a regression in a WHERE clause with a WF field
as the LHS and an addition operation on two WF fields on the RHS
is also fixed. The issue was SimpleColumn::getDecimalVal() was
setting precision = 19, with the value of one of the operands of the
addition operation being set in VDecimal::value instead of
VDecimal::s128Value. addSubtractExecute() in mcs_decimal.cpp makes the
assumption that if precision > 18 and precision <= 38, we need to
fetch the wide s128Value, not the narrow value field. So we are
fixing the precision set in SimpleColumn::getDecimalVal().
Since we now perform type promotion to wide decimals for aggregations
involving numeric fields, we need to check for wide decimal in
in and out ROWs and call the appropriate setter and getter functions.
Removed uint128 from joblist/lbidlist.*
Another toString() method for wide-decimal that is EMPTY/NULL aware
Unified decimal processing in WF functions
Fixed a potential issue in EqualCompData::operator() for
wide-decimal processing
Fixed some signedness warnings
For now it consists of only:
using int128_t = __int128;
using uint128_t = unsigned __int128;
All new privitive data types should go into this file in the future.
The else if block in Row::equals() was incorrectly getting triggered
for narrow decimals earlier. We now specifically check if the column
is a wide decimal. Furthermore, we need to dereference the int128_t
pointers for equality comparison.
1. Perform type promotion to wide decimal if the result
of an arithmetic operation has a precision > 18.
2. Only set the decimal width of an arithmetic operation to wide
if both the LHS and RHS of the operation are decimal types.
resulting expressions cannot be used as a template argument.
This is because the template instantiation happens at compile time
and cannot depend on the runtime value of the evaluating expression.
WF::percentile runtime threw an exception b/c of wrong DT deduced from its argument
Replaced literals with constants
Tought WF_sum_avg::checkSumLimit to use refs instead of values
v5 (current) version of the extent map supports int128_t min/max
values. This commit provides upgrade capability to load_brm program
that when reads an extent map saved to disk earlier with save_brm,
with a EM_MAGIC_V4 entry, converts it to the current v5 "wider"
extent map.
This commit also adds support in TupleHashJoinStep::forwardCPData,
although we currently do not support wide decimals as join keys.
Row estimation to determine large-side of the join is also updated.
