From: Jorgen Loland Date: February 9 2011 9:12am Subject: Re: bzr commit into mysql-trunk branch (jorgen.loland:3605) Bug#59793 List-Archive: http://lists.mysql.com/commits/130807 Message-Id: <4D525A8B.7040401@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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. > > 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. Since Item_xor_cond has mimiced the behavior of Item_func, I think (based on what I've seen when working on the XOR item) that it is * much more work and risk involved in making it a proper Item_cond instead of Item_func. The reason for both is that a lot of our code use these in an implicit manner [1] * almost the same amount of work to make Item_xor_func a proper Item_cond as it is to make the current Item_func-behaving Item_xor_cond a proper Item_cond. I have created WL#5800 for this task, but I think it should be done as part of item tree refactoring. I volunteer to do this WL at the point we decide to start that activity. [1] See WL#5800 -- Jørgen Løland | Senior Software Engineer | +47 73842138 Oracle MySQL Trondheim, Norway