From: Jorgen Loland
Date: February 9 2011 7:59am
Subject: Re: bzr commit into mysql-trunk branch (jorgen.loland:3605) Bug#59793
List-Archive: http://lists.mysql.com/commits/130799
Message-Id: <4D52494B.8070809@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 02/08/2011 02:55 PM, Øystein Grøvlen wrote:
> On 02/08/2011 01:08 PM, Roy Lyseng wrote:
>> Hi Jørgen,
>>
>> On 07.02.11 15.07, Jorgen Loland wrote:
>>> #At file:///export/home/jl208045/mysql/mysql-trunk-59793/ based on
>>> revid:tor.didriksen@stripped
>>>
>>> 3605 Jorgen Loland 2011-02-07
>>> Bug#59793: crash in Item_field::register_field_in_read_map
>>> with view
>>>
>>> Prior to the refactoring in this patch, Item_cond_xor behaved
>>> partially as an Item_cond and partially as an Item_func. The
>>> reasoning behind this was that XOR is currently not optimized
>>> (thus should be Item_func instead of Item_cond), but it was
>>> planned optimize it in the future (thus, made Item_cond anyway
>>> to ease optimization later).
>>
>> I dislike this solution, because conceptually an XOR is an Item_cond,
>> regardless of whether it is being optimized or not, and regardless of
>> whether an optimization is planned for it.
>
> IIUC, in the MySQL code an Item_cond represents a Boolean function with
> an unlimited number of arguments, while Item_bool_func2 is a Boolean
> function with two arguments. The current implementation of XOR can only
> operate on two arguments. Hence it is not really an Item_cond.

Yes, but conceptually XOR can operate on any number of operands >=2.

-- 
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway