When some subquery changes were made over a year ago the flag to state
that an UPDATE subquery was not constant data was accidentally commented
out. This brings it back in again.
When some subquery changes were made over a year ago the flag to state
that an UPDATE subquery was not constant data was accidentally commented
out. This brings it back in again.
Dumpcat was trying to pull in Perl's MySQL DBD as a dependency in RPM
builds. For 1.1 this causes conflicts so we can't do this. There are
alternative tools in ColumnStore to do the same thing as dumpcat.pl and
the SQL files are still there which is what the support tool uses.
We would get strange values for scale/precision in the results column of
a cross engine join causing bad results. This patch uses the values from
the libdrizzle client connector instead.
We would get strange values for scale/precision in the results column of
a cross engine join causing bad results. This patch uses the values from
the MariaDB client connector instead.
ExeMgr uses ResourceManager to count memory usage. If a usage exceeded
error occurs the counting wasn't reset and subsequent usage attempts in
the same ExeMgr thread would error.
This patch moves the in-class accounting for GroupConcat and others so
that it happens before the error is detected. The memory usage counter
is then decremented correctly on the class destructor.
ExeMgr uses ResourceManager to count memory usage. If a usage exceeded
error occurs the counting wasn't reset and subsequent usage attempts in
the same ExeMgr thread would error.
This patch moves the in-class accounting for GroupConcat and others so
that it happens before the error is detected. The memory usage counter
is then decremented correctly on the class destructor.
The LIKE part of the query for non-dict CHAR/VARCHAR was converted to an
INT based on the length of the column. So on a 2 byte CHAR a LIKE of
'%05%' was truncated to '%0' which is a very different query. We should
not cast this to INT because we could use a LIKE of > 8 bytes on a
non-dict column. This patch turns LIKE into an expressionStep which
cater for longer strings rather than a simpleFilter.
The LIKE part of the query for non-dict CHAR/VARCHAR was converted to an
INT based on the length of the column. So on a 2 byte CHAR a LIKE of
'%05%' was truncated to '%0' which is a very different query. We should
not cast this to INT because we could use a LIKE of > 8 bytes on a
non-dict column. This patch turns LIKE into an expressionStep which
cater for longer strings rather than a simpleFilter.
For LONGBLOB the string return length was 4GB for functions which got
converted to -1 and then to 20. This patch sets it to just under 2GB
which we use for LONGBLOB everywhere else.
