28.2.4 Writing Plugins
- 126.96.36.199 Overview of Plugin Writing
- 188.8.131.52 Plugin Data Structures
- 184.108.40.206 Compiling and Installing Plugin Libraries
- 220.127.116.11 Writing Full-Text Parser Plugins
- 18.104.22.168 Writing Daemon Plugins
- 22.214.171.124 Writing INFORMATION_SCHEMA Plugins
- 126.96.36.199 Writing Semisynchronous Replication Plugins
- 188.8.131.52 Writing Audit Plugins
- 184.108.40.206 Writing Authentication Plugins
- 220.127.116.11 Writing Password-Validation Plugins
- 18.104.22.168 Writing Protocol Trace Plugins
- 22.214.171.124 Writing Keyring Plugins
To create a plugin library, you must provide the required descriptor information that indicates what plugins the library file contains, and write the interface functions for each plugin.
Every server plugin must have a general descriptor that provides information to the plugin API, and a type-specific descriptor that provides information about the plugin interface for a given type of plugin. The structure of the general descriptor is the same for all plugin types. The structure of the type-specific descriptor varies among plugin types and is determined by the requirements of what the plugin needs to do. The server plugin interface also enables plugins to expose status and system variables. These variables become visible through the
SHOW STATUS and
SHOW VARIABLES statements and the corresponding
For client-side plugins, the architecture is a bit different. Each plugin must have a descriptor, but there is no division into separate general and type-specific descriptors. Instead, the descriptor begins with a fixed set of members common to all client plugin types, and the common members are followed by any additional members required to implement the specific plugin type.
You can write plugins in C or C++ (or another language that can use C calling conventions). Plugins are loaded and unloaded dynamically, so your operating system must support dynamic loading and you must have compiled the calling application dynamically (not statically). For server plugins, this means that mysqld must be linked dynamically.
A server plugin contains code that becomes part of the running server, so when you write the plugin, 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. These constraints may change in future versions of the server, so it is possible that server upgrades will require revisions to plugins originally written for older servers. For information about these constraints, see Section 2.9.7, “MySQL Source-Configuration Options”, and Section 2.9.8, “Dealing with Problems Compiling MySQL”.
Client plugin writers should avoid dependencies on what symbols the calling application has because you cannot be sure what applications will use the plugin.