Re: MySQL Reengineering Project

[Michael Widenius]

Hi!

>>>>> "Alaric" == Alaric Snell-Pym <alaric@stripped> writes:

<cut>

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