From: Tor Didriksen
Date: April 7 2011 7:08am
Subject: Re: bzr commit into mysql-5.1 branch (tor.didriksen:3644) Bug#11765713
List-Archive: http://lists.mysql.com/commits/134886
Message-Id: <4D9D62F9.40805@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2011-04-06 10:27, Sergey Glukhov wrote:
> Better place for the fix is matching_cond() function,
> the reason is that the function can not return TRUE
> if item evaluation is failed. So suggested fix
> could look like:
>
> == modified file 'sql/opt_sum.cc'
> --- old/sql/opt_sum.cc  2010-06-11 07:38:29 +0000
> +++ new/sql/opt_sum.cc  2011-04-05 10:39:44 +0000
> @@ -732,6 +732,9 @@
>
>      if (is_null || (is_null_safe_eq && args[1]->is_null()))
>      {
> +      if (current_thd->is_error())
> +        DBUG_RETURN(FALSE);
> +
>        part->field->set_null();
>        *key_ptr= (uchar) 1;
>      }
>
>
> Regards,
> Gluh

Hi Gluh

I like the idea of catching the error as early as possible, so I'll 
implement that.

However: opt_sum_query() should also catch the error, and return 
HA_ERR_XXX to JOIN::optimize:
  - that's the documented behaviour for opt_sum_query
  - if we don't return an error code, then the optimizer will continue 
(or *it* will have to check for thd->is_error)

I'm not so happy about changing the interface of matching_cond() and 
find_key_for_maxmin()
from
   @retval    false    Index can't be used.
to
   @retval    false    Index can't be used, or error has occured.
but I guess we cannot avoid it.

What do you think?

-- didrik