tags:

views:

348

answers:

2

There is a statement in the MySQL Docs (http://dev.mysql.com/doc/refman/5.0/en/adding-udf.html) that is bothering me:

"A UDF contains code that becomes part of the running server, so when you write a UDF, you are bound by any and all constraints that otherwise apply to writing server code. For example, you may have problems if you attempt to use functions from the libstdc++ library."

Why there may be problems if you use C++ standard library functions to write a UDF ??
Does that mean that I'm condemned to use plain old C to write my UDFs ?? (please say no)

A: 

Not having any knowledge at all of libstdc++, but going by the "For example" bit meaning that this warning is applicable to more than libstdc++ I would suggest that this means be wary of standard libraries in general as they may peform things that wouldn't work in a UDF environment.

For example (digging back to C) strtok maintains a local state between calls meaning you have to serialize its use or face corruption of its results if you tried to use it to work on two different strings at the same time. Thus strtok would not work in an environment like a UDF where you have no control as to where and when the function is called.

Thus I would say that anything that would not work in a multithreaded environment should be avoided.

But note that the above is based purely on my speculation, and is not based in reality.

Peter M
Oh, so the issue is thread-safety. Now things have more sense. I remember that STL had some problems when using threads.
GetFree
+2  A: 

In particular, your UDF must not permit ANY C++ exceptions to be thrown. All exceptions must be caught before returning from your UDF. This generally requires try/catch around any of the UDF that is going into C++ code, including a "catch (...)" clause if you're particularly paranoid.