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.
>
> Conceptually, XOR belongs together with AND and OR and should be treated
> as such. I am afraid that making XOR an Item_func will make some future
> changes difficult, even though I have no concrete suspicion of this.
In that case the future changes could change it to a subclass of
Item_cond, if that is necessary.
--
Øystein
