CI with RelWithDebInfo builds revealed a problem in the main
patch for MCOL-4464, which did not show up with Debug builds.
Methods like:
- getDoubleVal()
- getDateIntVal()
- getDatetimeIntVal()
- getTimestampIntVal()
- getTimeIntVal()
- getUintVal()
- getIntVal()
- getStrVal()
require the caller to initialize the isNull argument to false.
This fact was not taken into account in MCOL-4464.
Adding proper initializations.
For TIMESTAMP, it should do similar. However, it didn't work. For some reason, MDB has the function set as DATETIME, which for cs, isn't the same thing. Added a kludge to ha_mcs_execplan.cpp to handle it.
1. This patch adds support for wide decimals with/without scale
to cpimport. In addition, INSERT ... SELECT and LDI are also
now supported.
2. Logic to compute the number of bytes to convert a binary
representation in the buffer to a narrow decimal is also
simplified.
After creating and populating tables with CHAR(5) case insensitive columns,
in a set of consequent joins like:
select * from t1, t2 where t1.c1=t2.c1;
select * from t1, t2 where t1.c1=t2.c2;
select * from t1, t2 where t1.c2=t2.c1;
select * from t1, t2 where t1.c2=t2.c2;
only the first join worked reliably case insensitively.
Removing the remaining pieces of the code that used order_swap() to compare
short CHAR columns, and using Charset::strnncollsp() instead.
This fixes the issue.
A non-JOIN condition like `WHERE c1=c2` (with c1 and c2 being columns of the
same table) was not collation-aware yet after the main patches for MCOL-4064.
Additionally fixing StrFilterCmd::compare*() to address this.
MCOL-4409 This patch combines VDecimal and Decimal and makes
IDB_Decimal an alias for the result class
MCOL-4409 More boilerplate reduction in Func_mod
Removed couple TSInt128::toType() methods
1. Make PredicateOperator::setOpType() function wide decimal aware.
2. Added support for wide decimal in jlf_subquery.cpp::getColumnValue()
used in scalar subqueries.
3. Fixed the column index used for fetching wide decimal values from a Row
when a wide decimal field is used in the order by clause.
1. In BatchPrimitiveProcessorJL::countThisMsg(), exit early if the
return code from primproc is non-zero.
2. For statistical window functions (stddev/var), properly handle
the case when there is only one value for the calculation.
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.
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.
