Let's add a new plugin type: MariaDB_DATA_TYPE_PLUGIN.

plugin->data of such plugin will point to a single Type_handler implementation. So looking up a pluggable data type by name should be done very easy, by this code block:

  if ((plugin= my_plugin_lock_by_name(thd, &name, MariaDB_DATA_TYPE_PLUGIN)))

  {

    /*

      INSTALL PLUGIN is not fully supported for data type plugins yet.

      Fow now we have only mandatory built-in plugins

      and dynamic plugins for test purposes,

      Should be safe to unlock the plugin immediately.

    */

    const Type_handler *ph= reinterpret_cast<const Type_handler*>

                            (plugin_ref_to_int(plugin)->data);

    plugin_unlock(thd, plugin);

    return ph;

  }

Note, as the above comment states, for now we assume we have:

• mandatory built-in plugins
• dynamic test plugins, used by MTR in a single-thread environment
  so locking (incrementing and decrementing use count) is out of scope of this task and will be done separately.

Under terms of this task let's implement a simple test plugin implementing an alias for an existing data type, to demonstrate that the plugin data type is understood in various contexts:

• CREATE TABLE t1 (a XXX)
• CAST(expr AS XXX)
• CREATE FUNCTION f1() RETURNS XXX
• DECLARE a XXX; – SP variable declarations