The plugin framework is extendable to accommodate different kinds of plugins.

Some aspects of the plugin API are common to all types of plugins, but the API also allows for type-specific interface elements so that different types of plugins can be created. A plugin with one purpose can have an interface most appropriate to its own requirements and not the requirements of some other plugin type.

Although only the interface for full-text parser plugins is implemented currently, others can be added, such as an interface for UDF plugins.

The plugin API includes versioning information.

The version information included in the plugin API enables a plugin library and each plugin that it contains to be self-identifying with respect to the API version that was used to build the library. If the API changes over time, the version numbers will change, but a server can examine a given plugin library's version information to determine whether it supports the plugins in the library.

There are two types of version numbers. The first is the version for the general plugin framework itself. Each plugin library includes this kind of version number. The second type of version applies to individual plugins. Each specific type of plugin has a version for its interface, so each plugin in a library has a type-specific version number. For example, library containing a full-text parsing plugin has a general plugin API version number, and the plugin has a version number specific to the full-text plugin interface.

Plugin security is improved relative to the UDF interface.

The older interface for writing nonplugin UDFs allowed libraries to be loaded from any directory searched by the system's dynamic linker, and the symbols that identified the UDF library were relatively nonspecific. The newer rules are more strict. A plugin library must be installed in a specific dedicated directory for which the location is controlled by the server and cannot be changed at runtime. Also, the library must contain specific symbols that identify it as a plugin library. The server will not load something as a plugin if it was not built as a plugin.

The newer plugin interface eliminates the security issues of the older UDF interface. When a UDF plugin type is implemented, that will allow nonplugin UDFs to be brought into the plugin framework and the older interface to be phased out.

include/mysql/plugin.h exposes the public plugin API. This file should be examined by anyone who wants to write a plugin library.

sql/sql_plugin.h and sql/sql_plugin.cc comprise the internal plugin implementation. These files need not be consulted by plugin writers. They may be of interest for those who want to know more about how the server handles plugins.

The plugin table in the mysql database lists each installed plugin and is required for plugin use. For new MySQL installations, this table is created during the installation process. If you are upgrading from a version older than MySQL 5.1, you should run mysql_upgrade to update your system tables and create the plugin table (see Section 4.4.8, “mysql_upgrade — Check Tables for MySQL Upgrade”).

INSTALL PLUGIN registers a plugin in the plugin table and loads the plugin code.

UNINSTALL PLUGIN unregisters a plugin from the plugin table and unloads the plugin code.

The WITH PARSER clause for full-text index creation associates a full-text parser plugin with a given FULLTEXT index.

SHOW PLUGINS displays information about known plugins. The PLUGINS table in INFORMATION_SCHEMA also contains plugin information.

plugin_dir indicates the location of the directory where all plugins must be installed. The value of this variable can be specified at server startup with a --plugin_dir=path option.