27.2.1. Characteristics of the Plugin Interface
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
The plugin implementation includes the following components:
Source files (the locations given indicate where the files are
found in a MySQL source distribution):
include/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
Section 5.5.2, “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
plugin table and unloads the
WITH PARSER clause for full-text
index creation associates a full-text parser plugin with a
SHOW PLUGIN displays information about
known plugins. The
PLUGINS table in
INFORMATION_SCHEMA also contains plugin