In some respects, the plugin API is similar to the older user-defined function (UDF) API that it supersedes, but the plugin API has several advantages over the older interface:
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 non-plugin 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 non-specific. 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 non-plugin UDFs to be brought into the plugin framework and the older interface to be phased out.
The plugin implementation includes the following components:
Source files (the locations given indicate where the files are found in a MySQL source distribution):
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.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.
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
「mysql_upgrade — MySQL アップグレードのテーブル チェック」).
INSTALL PLUGIN registers a plugin in the
plugin table and loads the plugin code.
UNINSTALL PLUGIN unregisters a plugin
plugin table and unloads the
WITH PARSER clause for full-text
index creation associates a full-text parser plugin with a
SHOW PLUGINS displays information about
known plugins. The
PLUGINS table in
INFORMATION_SCHEMA also contains plugin
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