From: Michael Widenius Date: May 13 2009 11:39pm Subject: Re: MySQL Reengineering Project List-Archive: http://lists.mysql.com/internals/36678 Message-Id: <18955.23088.898890.123834@narttu.askmonty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! >>>>> "Alaric" == Alaric Snell-Pym writes: Alaric> That, combined with the fact that in my recent foray into UDFs I found Alaric> that string UDFs are passed a buffer with room for 255 characters to Alaric> put their result into, and then have the choice of using it and Alaric> returning a pointer to it or mallocing their own buffer and returning Alaric> a pointer to that (meaning that the caller, somewhere, must have code Alaric> to the effect of "if (returned_ptr != allocated_buffer) Alaric> free(returned_ptr)" to clear up, I guess?), Actually the idea was that you would in your object remember the malloc you did and then free it. So the code would be in the destructor: x_free(malloc_pointer); Alaric> led me to suspect that Alaric> there was an ingrained culture of functions plopping their results Alaric> into spaces left for them somewhere. The idea was to help the UDF to avoid doing mallocs during query execution for most common queries. The assumption was that for most UDF's 255 byte would be enough for their result. Alric> Ok, there's often good reasons Alaric> for string-processing functions to put their results into preallocated Alaric> buffers, but I suspect in this case somebody originally wrote it that Alaric> way because it was the ingrained culture, and then later had to add Alaric> the ability to malloc your own buffer (wasting the pre-allocated Alaric> buffer) in order to handle strings of more than 255 characters :-) No, the design was there from the start. One of the basic design of the MySQL code base is to try to avoid calls to malloc during query execution; We should instead try to do as much as possible when at query exceution startup. Alaric> Although I may have found the only examples of this sort of thing in a Alaric> very large and otherwise much more cleanly-structured codebase for all Alaric> I know! Regards, Monty