Hi Joro,
Georgi Kodinov wrote:
[skip]
> === modified file 'sql/item_cmpfunc.cc'
> --- a/sql/item_cmpfunc.cc 2009-10-05 05:27:36 +0000
> +++ b/sql/item_cmpfunc.cc 2009-11-04 10:45:19 +0000
> @@ -759,15 +759,20 @@ Arg_comparator::can_compare_as_dates(Ite
>
> if (cmp_type != CMP_DATE_DFLT)
> {
> + THD *thd= current_thd;
> /*
> Do not cache GET_USER_VAR() function as its const_item() may return TRUE
> for the current thread but it still may change during the execution.
> + Don't cache subqueries : this is because they'd be evaluated at
> + prepare and this can confuse some storage engines since some
> + statements (e.g. SHOW CREATE TABLE) are not locking the tables.
> +
> */
> - if (cmp_type != CMP_DATE_WITH_DATE && str_arg->const_item()
> &&
> + if (!thd->is_context_analysis_only() &&
> + cmp_type != CMP_DATE_WITH_DATE && str_arg->const_item()
> &&
> (str_arg->type() != Item::FUNC_ITEM ||
> ((Item_func*)str_arg)->functype() != Item_func::GUSERVAR_FUNC))
> {
IMO the comment doesn't reflect the change correctly. It's not that we don't
cache subqueries only, but we're not using cache at all in some circumstances.
I propose to add something like this:
Don't use cache while in the context analysis mode only (i.e for EXPLAIN/CREATE
VIEW and similar queries). Cache is useless in such cases and can cause
problems. For example evaluating subqueries can confuse storage engines since
in context analysis mode tables aren't locked.
Regards, Evgen.
