From: Roy Lyseng Date: February 8 2011 2:06pm Subject: Re: bzr commit into mysql-trunk branch (jorgen.loland:3605) Bug#59793 List-Archive: http://lists.mysql.com/commits/130729 Message-Id: <4D514DE4.9050903@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 08.02.11 14.55, Ø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. I consider it an "Item_cond" because it is on the same level as AND and OR in the syntax diagrams. Whether it takes two or more arguments is strictly not relevant. The reason that Item_cond for AND and OR can take more than two arguments is the optimization of such functions, and not based on syntax. Roy